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

validation of VERSION_KEY (core:version is currently unconditionally set to 1.0.0) #54

Closed
anarkiwi opened this issue Apr 4, 2024 · 3 comments

Comments

@anarkiwi
Copy link
Contributor

anarkiwi commented Apr 4, 2024

Thanks so much for SigMF python, and the included validator!

One of my tools was missing core:version, but sigmf_validator found no errors. I found that is because version is unconditionally overwritten to 1.0.0 no matter what (see

self._metadata[self.GLOBAL_KEY][self.VERSION_KEY] = '1.0.0'
among others).

According to https://github.com/sigmf/SigMF/blob/sigmf-v1.x/sigmf-spec.md#sigmf-collection-format, core:version is required.

I can raise a PR to remove the explicit set so that validation fails where the version is not present/and or is set to an unexpected value. Is that the desired behavior?

@Teque5
Copy link
Collaborator

Teque5 commented Apr 4, 2024

I believe the validation should fail if the version key is absent.

With respect to your question about what version is considered valid the Specification is currently labeled 1.0.0, however I have an open issue sigmf/SigMF#297 that tries to resolve some inconsistencies in the spec versioning and update that value.

With respect to how this module will track what is a valid core:version, we have had a few discussions without resolution. It makes sense for the validator to be able to check multiple versions of the specification, but since the schema currently lives in this repo we only have one version to check. There is an effort in the specification repo to create/maintain the schema there (sigmf/SigMF#275 & sigmf/SigMF#276), in which case the SigMF spec could be a git submodule of sigmf-python and in turn we could check the schema of whatever version is tagged.

The current effort on this topic is in sigmf/SigMF#301 where @777arc wants to generate the spec directly from the schema. If that PR is merged we will likely delete the schema from this repo and go with a submodule unless someone floats a better idea.

@anarkiwi
Copy link
Contributor Author

anarkiwi commented Apr 5, 2024

Ah that will be very nice (separate schema definition). I put in a PR to not overwrite VERSION_KEY in the meantime.

@Teque5 Teque5 closed this as completed Apr 12, 2024
@Teque5
Copy link
Collaborator

Teque5 commented Apr 12, 2024

Closed with PR #55.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants