-
Notifications
You must be signed in to change notification settings - Fork 185
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
"location-uuid" (Location Universally Unique Identifier Reference) is both a field and a flag in metadata metaschema. Is this a bug? #2056
Comments
Having to account for identical names for instances of different types will make the specification more complex to create as code and use as a library. I'll add an Issue in the metaschema repo as well, since I guess it needs to be fixed there. |
@RS-Credentive - Thank you for your question. The code you point to was inserted 3years 7 months ago by a team member no longer with us. I will need to research it with @wendellpiez before addressing it. |
Good discussion of the theoretical issues over on usnistgov/metaschema#781, but for OSCAL specifically, I have noticed that location-uuid is defined as a field and a flag, but only the field reference is used, so it appears the flag definition could be eliminated without any impact to any other OSCAL model. The field reference is here:
I haven't seen any other reference to "location-uuid" except in the context of constraints. |
I know this PR has been merged and the issue will likely be closed, but from the perspective of a Metaschema definition, a "global" level field definition like below that is Metaschema processors, the XSLT, the Java, and any conformant with the spec should not process it and ignore it. Aside from that, assembly, field, and flag definitions, even if they were not a no-op must be handled separately and duplicate name collision avoidance is a requirement. The @name attribute provides the definition’s identifier, which can be used in other parts of a module, or in an importing Metaschema module, to reference the definition. In top-level definitions, this attribute’s value MUST be a token that is unique among sibling definitions of the same type.
https://pages.nist.gov/metaschema/specification/syntax/definitions/#top-level-define-field Again, it's a no-op, and the lack of a paired
https://pages.nist.gov/metaschema/specification/syntax/instances/#field-instance So removing it is definitely a good thing, but it is specifically not a bug. This is why documentation and derivartive JSON Schemas and XML Schemas do not mention definitions that are not https://pages.nist.gov/metaschema/specification/syntax/instances/#field-instance |
Thank you @aj-stein-gsa. If it's any help, an XPath on a metaschema module document can determine whether a global definition is referenced in that document. However this is not conclusive when modules are combined into models since the scope of the query is the file instance. One can write a query to search a set of instances. Or a process such as metaschema-xslt "metaschema composition" can be extended to report on these. Easier: since a @ref to something that can't be found will be a static error in a metaschema build, the simplest test might be to remove the definition and try to produce any/all models that use the module (all of them in this instance). It should blow up for a reference that can't be resolved. Note that the semantics here are also complicated by the metaschema |
Question
While parsing Flags and Fields in oscal_metadata_metaschema.xml, I discovered that "location-uuid" is defined as both a field and a flag. This causes issues when generating code from the metaschema definition because the names conflict. Is this an intentional feature or a bug?
The text was updated successfully, but these errors were encountered: