jechterhoff
commented
4 months ago This issue has the risk of further complicating the JSON Schema encoding requirements regarding primary time. The interested reader is referred to the documentation of the ShapeChange conversion rule for JSON-FG primary time.
In my opinion, we should take a step back to review the matter from a more general perspective. We could try to nail down the contents of the top-level "time" member in a JSON-FG feature, depending upon the definitions of primary time properties in an application schema. That is what we already do, to a certain extent. We could go further with that, as described in the ShapeChange conversion rule. But: is that level of complexity really needed? Probably not. The resulting complexity would be big, while the added benefit would be small. We already know that JSON Schema validation is incomplete. Think about validation of property values, where the value type is a supertype - only the supertype constraints will be checked. Being able to validate the presence of date, timestamp, and interval within the top-level "time" member, based upon the definition of primary time UML properties, does not appear to be a significant benefit.
Proposal:
- Do not create any constraints for the top-level "time" member. Just require that the primary time property / properties not be encoded within the "properties" member, and that in instance data, the property value shall be encoded within the (JSON-FG) time member.
- If, in the future, further validation was requested, we could add that to the specification.
@PalmJanssen: Let's discuss the proposal.
PalmJanssen
We need to be more clear about how the multiplicity of the UML property or UML properties that are mapped to the top-level “time” member is taken into account. This is somewhat similar to the considerations for primary geometry and primary place (see #47), but is much more complicated.
According to JSON-FG, it is allowed that “time” has both date/timestamp and an interval. We should probably make that more explicit, especially that JSON-FG has certain requirements for such a case.
The case that a feature type defines both a primary instant as well as a primary interval is currently not covered by the requirements in the Best Practice document, chapter 7.7.4. In fact, the whole section should be revised in order to correctly take into account the multiplicity and presence of UML properties that constitute a primary instant or primary interval. The new ShapeChange conversion rule (rule-json-cls-primaryTime - for the next release) could be used as a template for the revision of chapter 7.7.4.
We should provide an example that includes a "time" restriction for both date/timestamp and interval.