Open RS-Credentive opened 4 weeks ago
RS-Credentive
commented
4 weeks ago 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.
iMichaela
commented
3 weeks ago @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.
RS-Credentive
commented
3 weeks ago Good discussion of the theoretical issues over on https://github.com/usnistgov/metaschema/issues/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: https://github.com/usnistgov/OSCAL/blob/4f02dac6f698efda387cc5f55bc99581eaf494b6/src/metaschema/oscal_metadata_metaschema.xml#L303
I haven't seen any other reference to "location-uuid" except in the context of constraints.
aj-stein-gsa
commented
1 week ago 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 <field ref="...">ed later is essentially a no-op.
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.
Note: The names of flags, fields, and assemblies are expected to be maintained as separate identifier sets. This allows a flag definition, a field definition, and an assembly definition to each have the same name in a given Metaschema module.
https://pages.nist.gov/metaschema/specification/syntax/definitions/#top-level-define-field
Again, it's a no-op, and the lack of a paired @ref makes this a moot point.
The @ref attribute MUST reference a top-level field definition’s @name that is in scope. See Definition Name Resolution for a detailed explanation of definition name scoping.
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 refed.
https://pages.nist.gov/metaschema/specification/syntax/instances/#field-instance
wendellpiez
commented
1 week ago 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 @scope attribute (iirc scope='local' restricts a top-level definition to 'private' vs 'public' use).
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?