Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add property to detect JSON FG and its version number #70

Closed
m-mohr opened this issue Sep 14, 2022 · 3 comments · Fixed by #84
Closed

Add property to detect JSON FG and its version number #70

m-mohr opened this issue Sep 14, 2022 · 3 comments · Fixed by #84
Assignees

Comments

@m-mohr
Copy link

m-mohr commented Sep 14, 2022

It might be useful to have something in the file that fulfills two purposes:

  1. Indicate that the file is a JSON FG file (because otherwise you need to scan through all potential properties/extensions)
  2. Indicate the implemented version of JSON FG

This could be two properties, but it could also be a single property.

For the case that it's a single property, I have two ideas in mind:

  1. Add a jsonfg_version (or similar) property that holds the version number.
    Example: "jsonfg_version": "0.1.0"
  2. Use the "conformsTo" from OGC APIs and add a link to the versioned JSON FG JSON Schema.
    Example "conformsTo": ["https://example.com/jsonfg/v0.1.0/schema.json"]
@IvanSanchez
Copy link

I'm partial to the conformsTo approach, since it would allow signalling optional conformance classes.

@cportele
Copy link
Member

Meeting 2022-10-31: Such a hint is valuable and should be added. We are leaning towards the "conformsTo" so that the conformance classes can be identified by the generating and consuming software. The values of "conformsTo" would be the conformance class URIs (e.g. "http://www.opengis.net/spec/json-fg-1/0.1/conf/core"). Of course, parsing the URIs to extract the version number is a bit of a hassle, so maybe the version should also be provided in a separate member? Comments are welcome.

@cportele cportele self-assigned this Jan 9, 2023
@cportele
Copy link
Member

cportele commented Jan 9, 2023

Meeting 2023-01-09: We think this is necessary and given that we did not receive any comments, we will move forward with a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants