[Requests] Comments on 15-100r1

Charles Heazel CHeazel at wiscenterprises.com
Fri Jan 29 21:23:42 EST 2016


PART A


1. Evaluator:  Charles Heazel

2. Submission:  15-100r1 OGC Observations and Measurements - JSON Implementation

PART B

1. Requirement: Typographic errors

2. Implementation Specification Section number: Multiple

3. Criticality: Editorial

4. Comments/justifications for changes:
Title - "Implementation" should be capitalized
2.1 Overview - remove duplicate word "a general solution to specifying this target this is more"
2.2 Conformance Classes - "OGC Compliance Testing web site1."

PART C

1. Requirement: General

2. Implementation Specification Section number: Vi Changes to the OGC Abstract Specification

3. Criticality: Editorial

4. Comments/justifications for changes:
               Concur with these recommendations.  They reflect some of the issues I had when reviewing the SensorThing model.
Note that featureOfInterest and observeredProperty are required roles for OM_Observation.  These constraints need to be relaxed when the Observation Collection class is used.  PhenomenonTime and resultTime are mandatory properties of OM_Observation and arguably should remain mandatory.

PART D

1. Requirement: General

2. Implementation Specification Section number:
3 Normative References
Requirement /req/base/json

3. Criticality: Editorial

4. Comments/justifications for changes: A discussion of why ECMA-404 is cited rather than IETF RFC 7159 would be useful.

PART E

1. Requirement: General

2. Implementation Specification Section number: Section 3 Normative References

3. Criticality: Editorial

4. Comments/justifications for changes:
Add an Informative References section for citations which are relevant to this specification.  Include citations for:

*        JSON Schema: interactive and non-interactive validation - http://tools.ietf.org/html/draft-fge-json-schema-validation-00

*        GeoJSON - https://datatracker.ietf.org/doc/draft-ietf-geojson/

*        JSON-LD - https://www.w3.org/TR/json-ld/

Since compliance is defined in terms of JSON Schema validation, the supporting validation document (not a standard) is relevant.
GeoJSON is used but not cited.
JSON-LD techniques are used in this specification.  We should acknowledge the source and seek to align them as much as possible.

PART F

1. Requirement: General

2. Implementation Specification Section number: 6.1 Use of JSON

3. Criticality: Editorial

4. Comments/justifications for changes: As we start aggregating observations we will need a JSON-LD encoding as well.  The "type" and "id" properties are consistent with the JSON-LD @type and @id properties.   The better we align JSON and JSON-LD today the less remediation we will have to do latter.  Personally I find the use of "@" to designate well known properties to be a valuable tool.  For example, "@id" is the universally unique identifier, "id" can be context specific.

PART G

1. Requirement: JSON Base Types

2. Implementation Specification Section number:
6.1 Use of JSON
7.2 JSON Base Types

3. Criticality: Major

4. Comments/justifications for changes:
The examples given in section 7.2 do not include the "type" property in the JSON objects.
This is appropriate for these base classes where the single property name also signals the object class.  However, there is no discussion of this pattern in section 6.1.  6.1 should include this discussion and also be explicit about when "type" is required and when it is not.
Also, the examples for more complex classes should include the "type" and preferably the "Id" property.

PART H

1. Requirement: /req/base/link

2. Implementation Specification Section number: 7.2 JSON Base Types

3. Criticality: Editorial

4. Comments/justifications for changes: This is one place where @context would be very useful.  Could we or should be work it in?

PART I

1. Requirement: /req/time-series/metadata

2. Implementation Specification Section number: Example

3. Criticality: Minor

4. Comments/justifications for changes:
               "commentBlocks" is an array so it would be good to show more than one element.
Since an array is an ordered set, how are they ordered?

PART J

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Editorial

4. Comments/justifications for changes:
               Nice job.  I have not reviewed against the UML model and JSON Schema.  There may be more to come.


Charles Heazel
WiSC Enterprises
703-380-7433

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20160129/6ed9f0a3/attachment-0001.html>


More information about the Requests mailing list