-
Notifications
You must be signed in to change notification settings - Fork 76
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
keys in the top object #218
Comments
SigMF There is some overlap in the key names from keys within sigmf-meta top level objects and sigmf-collection |
Yes, but I think all of what you said is already in the spec, and you didn't address the asymmetry in allowance of top level fields like I'd hoped. I'm not hung up on this question, and if there's not a good answer then I can just close it I guess. |
I must be missing something. Are you asking why collections files cannot have |
Sorry let me back up. Both recordings and collections have a canonical set of top-level keys; in the case of recordings, that set is of size 3, whereas for collections it's 1. The asymmetry I observe in the spec is that it's apparently allowed for there to exist other top-level keys (outside of their respective canonical set) in a .sigmf-meta file but not in a .sigmf-collection file. |
Additional top level keys are not permitted in compliant metadata or collections. For Metadata:
For Collections:
Extensions are not permitted to create additional top level keys as far as i know though this could probably be more explicit in the spec. I think we can sharpen some of this to make it more clear "The top-level Object MUST contain exactly three JSON Objects" It is possible to have noncompliant but still functional and useful SigMF schema though, just not something we really advocate users do. |
I agree that it could/should be sharpened, but here's the line that led me to believe that extensions could add new top-level, under
Oh, does "SigMF Objects" refer to additional files?? Surely not ... at least now you know what wording let me to believe that other top-level key words were allowed. And as I tried to originally state, I support the concept of only allowing those 3 key words at the top level. |
Hm. This is not something I was aware of and is somewhat problematic. Will think on it. |
Is this still what we want? Specifically should new top level metadata keys or "new files" really be permitted by extensions? |
poke @bhilburn |
Going to close this out. Collections are intentionally very narrow in scope, while Recordings can be created to contain a wide range of data which may cause users to wish to have the freedom to create new top level objects. The spec is consistent in that metadata files must contain at least those three top level objects, and collections are restricted to the single top level object. On some level I would have probably liked to limit the metadata to those three top level keys but this is out there and its fine as far as i can tell. If there are breaking use cases here [for collections], lets address them specifically. |
I see that an asymmetry exists between
.sigmf-meta
files and.sigmf-collection
files in that other keys besides "global", "captures", and "annotations" are allowed to be defined by the user (via an extension) for meta, but that collections may only have a single"collection"
key.Was this difference deliberate? Is there rationale for this besides my guess that the concept of a collection is very narrow in scope, whereas the metadata for recordings involves more unknowns?
For myself, I wish that only "global", "captures", and "annotations" were allowed at the top level for a recording, thereby forcing the user to decide whether it's a global concept or not.
The text was updated successfully, but these errors were encountered: