practical questions about schema

[gmabey]

1. should all keys identified in a schema JSON file be required to have the same namespace? (all characters before the first ":")
2. should the name of the schema file be required to identify that namespace? If so then sigmf-schema.json would be renamed core-schema.json, for example. Is there a better way to definitely indicate the namespace of a schema? Or maybe a requirement that implies sigmf-core-schema.json, sigmf-antenna-schema.json.
3. can a key have more than one : in it?
4. I understand [1] that there's no convention within the JSON schema to indicate a version number. That leaves the "$schema" field, which could have a version number embedded in it, as does that value in antenna-schema.json. This implies that the "version" field in the spec could change to "schema" which would inherently include a name and a version. If you buy into that, then perhaps the "name" field should change to "namespace" ...

One conundrum I'm experiencing (that is motivating these questions) is that I attempted to validate a .sigmf-meta file against antenna-schema.json and it failed, because antenna:model is required. That's fine, but I see a need to correlate an item in "core:extensions" with a specific .json file, so that they can be selectively applied.

If we agree that the namespace should be part of the schema filename, then I wonder whether there's a good reason for containing the community extensions within subdirectories. That is, if the file name contains the namespace, then that ought to be good enough for uniqueness. Any other information regarding the author or origin of the schema should probably be contained in "description", no?

[1] https://stackoverflow.com/questions/61077293/is-there-a-standard-for-specifying-a-version-for-json-schema

[777arc]

Lots of great points!

Regarding the name of the files, it's common to use something-schema.json to distinguish it from any old JSON file, so that's where that came from.

For versioning we've been using github tags and then referencing it in the id as https://raw.githubusercontent.com/sigmf/SigMF/v1.2.2/sigmf-schema.json so sounds like the suggestion is to use that value for the schema field too?

[gmabey]

yeah -- here's a branch https://github.com/gmabey/SigMF/tree/revised_extensions

[Teque5]

1. should all keys identified in a schema JSON file be required to have the same namespace? (all characters before the first ":")

Yes

2. should the name of the schema file be required to identify that namespace? If so then `sigmf-schema.json` would be renamed `core-schema.json`, for example. Is there a better way to definitely indicate the namespace of a schema? Or maybe a requirement that implies `sigmf-core-schema.json`, `sigmf-antenna-schema.json`.

{namespace}-schema.json (core-schema.json etc) make sense.

3. can a key have more than one `:` in it?

As long as the documentation & schema parsing software allow that, then yes.

4. I understand [1] that there's no convention within the JSON schema to indicate a version number. That leaves the `"$schema"` field, which could have a version number embedded in it, as does that value in `antenna-schema.json`. This implies that the `"version"` field in the spec could change to `"schema"` which would inherently include a name _and_ a version. If you buy into that, then perhaps the `"name"` field should change to `"namespace"` ...

Agree namespace key within core:extensions makes more sense. Maybe we should make this change soon since there is pending support in the python module for validating this information. This would be an increment to the MINOR version.

As for the version of the schema we discussed in the monthly call that we aren't synchronizing everything and we may need a process for that. We may need a separate issue for this. We need to synchronize:

• GitHub Release
• $id field within schemas
• commit tag

[Teque5]

yeah -- here's a branch https://github.com/gmabey/SigMF/tree/revised_extensions

Looks pretty good, but $id can be any URI. Should the examples include a local file path similar to those found in wikipedia examples?

Since $id may not include the version #, perhaps that field should be kept?

[gmabey]

Looks pretty good, but $id can be any URI. Should the examples include a local file path similar to those found in wikipedia examples?

Hmm -- like a local file:// reference? It would have to be relative, and I don't think that's going to end well.
In the json-schema-validate source code, "$id" values are used as unique keys -- without any machinery to retrieve them. But, if you want/need to retrieve it, you can see where it get that precise version.
Without any additional experience in this regard, I can only assume that this is the intent of the JSON schema authors.

As I've been looking at the "meta schema" https://json-schema.org/draft/2020-12/schema and I see an interesting feature that may be pertinent here: "$dynamicAnchor". However, that may only be pertinent if we end up (eventually) defining types (like, reduce the boiler-place associated with 2**63-1 integers) or breaking up sigmf-schema.json into multiple files.

Could get complicated!

Since $id may not include the version #, perhaps that field should be kept?

So, I tried to include a "solution" to this very important concept here: sigmf-wifi-schema.json line 3
However, it's geared toward the community extensions, which will surely have a "unique" release/versioning procedure.
Do you think that all of "version", "original author", "current maintainer" will apply to standard extensions?

[gmabey]

2. should the name of the schema file be required to identify that namespace? If so then sigmf-schema.json would be renamed core-schema.json, for example. Is there a better way to definitely indicate the namespace of a schema? Or maybe a requirement that implies sigmf-core-schema.json, sigmf-antenna-schema.json.

{namespace}-schema.json (core-schema.json etc) make sense.

I think I like sigmf-wifi-schema.json because it hints that it builds off of the core schema, and sigmf-core-schema.json is the natural generalization of that scheme.
</just_a_suggestion>