search

sacmwg / draft-ietf-sacm-coswid

Concise Software Identifiers
Other
2 stars 5 forks source link

What is the extension story around global-attributes? #21

Closed thomas-fossati closed 3 years ago

thomas-fossati commented 4 years ago

The omnipresent global-attributes has an any-attribute sub-group with apparent unbounded freedom to pick a label. AFAICS, this extension point is not governed by a registry or an allocation policy. So it's not clear to me how do we plan to prevent clashes?

(Note that the SWID equivalent seems to be BaseElement's anyAttribute, which has proper namespace separation. The relevant SWID XSD comment says: "Allows any undeclared attributes on any element as long as the attribute is placed in a different namespace.")

Maybe I am just confused and it all works fine, but I think that the envisaged extension story around global-attributes needs to be made a bit clearer.

henkbirkholz commented 4 years ago

Potentially addressed by #29.

But even "contained" in their own map, the any-attributes can never be validated and should be processed with care. The namespace checking for the any-attribute in the ISO XSD is set to lax, which allows for omission of a namespace.

The closest "equivalent" to "any-attributes that have their own schema and namespace" in CDDL is the definition of extension CDDL using the existing sockets.

The closest "equivalent" to "any-attributes that have no schema or namespace" in CDDL is the use of the any-attribute (now augmented by the proposal to contain them in their own map).

thomas-fossati commented 4 years ago

The namespace checking for the any-attribute in the ISO XSD is set to lax, which allows for omission of a namespace.

"lax" only means that if the XML processor hasn't been able to retrieve the schema for validating the attributes from that namespace, it won't fail validation. It doesn't mean you can omit the namespace.

thomas-fossati commented 4 years ago

closed by accident, not sure what button got pushed... :-)

henkbirkholz commented 4 years ago

Which maps to using a placeholder namespace and never providing it. A machine will never be able to infer the difference and therefore - semantically and in consequence implementation-wise - lax breaks down to the expect-able worst case of: there will never be any kind of validation for this.

But I have to admit, I am approaching the problem a bit formally, as I am generating and validating XML... let's say rarely :-)

henkbirkholz commented 3 years ago

The summary we settled on and now reconfirmed is this:

While XML SWID require a namespace for extension for validation, they can be verified without a supplied XSD. This allows for un-verified portions of XML where no XSD can be acquired or is defined. We map this behavior via extension points that mandate a CDDL (analogous to XML namespace ##Other) and then allow for the any-attributes (analogous lax contentProcess and the XML any attribute).

An errata to XML SWID might come up in the future, but now we are sticking with similar expressiveness.

henkbirkholz commented 3 years ago

We can resurrect this issue, if need be. For now I'll bury this in is:closed.