Jacob Gilbert

Validation is indeed an area we need help with. Are there other problems with the schema besides not having extension fields in it?

To add to Marc's point on individual extension schemas, adding them to a monolithic schema is unappealing since it makes it harder for people to validate just what they care...

Hello @igorauad - thank you for submitting this! I'd like to redirect this PR to the new https://github.com/sigmf/community-extensions repository, where I hope to move almost all signal-specific, and many other...

Hi @PeterisP - I think I understand generally what you are looking to see here but I could use a little more info to best answer this. My initial thought...

Ok, thanks for expanding. Having tens of thousands of files open (and dealing with the associated thrashing) is certainly something to avoid, so that makes a lot of sense. One...

@PeterisP I've continued to think about this, and allowing "collections of collections" seems to make a lot of sense to me. I have opened #272 for discussion of this aspect...

Do we have a process for extension schemas to be written?

All of this sounds appropriate for an extension, maybe `sigmf-integrity` or something. The `core` namespace checksum is 100% optional, and if sha512 is a problem users are free to define...

Captures scope geolocation is probably reasonable, though we cannot remove the global scope field for a while. Annotations (where geo info used to be) should probably go into the `spatial`...

Sorry, that was pretty vague. I think if global was undesirable we could formally deprecate in 2.0 and then remove in 3.0? Adding this to captures seems reasonable though.