"location-uuid" (Location Universally Unique Identifier Reference) is both a field and a flag in metadata metaschema. Is this a bug?

[RS-Credentive]

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?

[RS-Credentive]

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]

@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]

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:

OSCAL/src/metaschema/oscal_metadata_metaschema.xml

Line 303 in 4f02dac

<field ref="location-uuid" max-occurs="unbounded">

I haven't seen any other reference to "location-uuid" except in the context of constraints.

[aj-stein-gsa]

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.

https://github.com/usnistgov/OSCAL/blob/v1.1.2/src/metaschema/oscal_metadata_metaschema.xml#L449-L462

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]

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).