#15 QName handling is partially undefined for DPWS/WS-Discovery

[David]

This is a major issue that also affects BICEPS. So far I wasn't able to figure out any resolution for this ambiguity, so any input that helps in clarifying the problem is highly appreciated. The problem is also described here: https://www.w3.org/2001/tag/doc/qnameids and can be concluded exemplarily if looking at the QName resolution rules described here: https://www.w3.org/TR/xmlschema-1/#src-qname

QNames are defined for elements and attributes in XML instances, but are lacking a general definition for element and attribute values. So whenever there is an XML grammar that requires an XML instance to enclose QNames in element or attribute values, the grammar also needs to define how to handle QNames without prefixes (i.e. do they come as namespace-less QNames or is a default namespace applied based on the enclosing XML instance).

Moreover, the XML processor that parses the XML instances needs to provide a prefix-to-namespace mapping context in order to facilitate QName assembly during XML element and attribute value processing.

The issue came up when JAXB created a prefix-less QName during marshalling but missed to unmarshal it back to the QName that was put into the JAXB marshaller beforehand.

What's the implication for MDPWS (and even BICEPS)? We need to define how to handle QNames in XML instances explicitly as DPWS and WS-Discovery missed to define such constraints. From this it follows that DPWS and WS-Discovery cannot be used without ambiguities if not based on another application restriction.

We might also face the problem that a good portion of XML processors are not capable of serving the needs for element and attribute value QName resolution.

---

EDIT: further resources: https://www.w3.org/2001/tag/doc/qnameids.html

[Stefan Schlichting]

Can you provide an example where the problem occurred in the SOAP message/XML snippet?

[David]

<wsd:Types xmlns="http://standards.ieee.org/downloads/11073/11073-20702-2016">
    dpws:Device MedicalDevice
</wsd:Types>

[David]

And there isn't even a rule how the prefixed QName is supposed to be resolved. It's just based on common sense.

[Stefan Schlichting]

The definition of QName can be found here:
https://www.w3.org/TR/xmlschema-2/#QName

...The ·lexical space· of QName is the set of strings that ·match· the QName production of [Namespaces in XML].
Note:The mapping between literals in the ·lexical space· and values in the ·value space· of QName requires a namespace declaration to be in scope for the context in which QName is used.

[Namespaces in XML] The reference resolves to
https://www.w3.org/TR/1999/REC-xml-names-19990114/

In section 3 (Qualified Names) it is stated:

The Prefix provides the namespace prefix part of the qualified name, and must be associated with a namespace URI reference in a namespace declaration.

The mechanism of namespace declaration is defined in section 2 (Declaring Namespaces) of that document.

The usage of QNames is laid out in section 4 (Using qualified names). It focuses on the usage of elements and attributes, but it also has a more general note that helps to resolve both qnames from the example.

Namespace Constraint: Prefix Declared
The namespace prefix, unless it is xml or xmlns, must have been declared in a namespace declaration attribute in either the start-tag of the element where the prefix is used or in an an ancestor element (i.e. an element in whose content the prefixed markup occurs).
The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. The prefix xmlns is used only for namespace bindings and is not itself bound to any namespace name.

As the example defines the default namespace in the ancestor element, "MedicalDevice" should be resolved to (http://standards.ieee.org/downloads/11073/11073-20702-2016, MedicalDevice) and dpws:Device to (http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01, Device) under the assumption that the namespace dpws is declared in one of the ancestor elements that is not shown in the xml snippet.

[David]

Hm, I read it twice, but I don't see the hint that resolves the QName-as-value dilemma. :-/ Two points that puzzle me:

• Your emphasized sentence talks about markup, and according to XML, markup does not include element content.
• Where is the requirement that prefix-less QName values have to be interpreted based on the default namespaces? This ruleset is defined for attributes and elements only.

As the example defines the default namespace in the ancestor element, "MedicalDevice" should be resolved to (http://standards.ieee.org/downloads/11073/11073-20702-2016, MedicalDevice)

That's exactly the problem: there is no rule that stipulatesMedicalDevice to be resolved from the default namespace since it is a value and not an element or attribute. An XML processor can roll a dice to take a decision on how it likes to handle the local QName (which JAXB seems to do :-) ) unless you explicity rule one option out. And btw. as already mentioned, when being strict it's also undefined how prefixed QName values have to be resolved.

I would tend to come up with a ruleset specific to MDPWS and BICEPS that clarifies QName value resolution.

[Stefan Schlichting]

I updated my markup and excluded the example.
And if you read it now than it says :

The namespace prefix, ..., must have been declared in a namespace declaration attribute ... in an ancestor element.

It should be noted that the start-tag partof the text above is needed if the qname is used inside of an attribute as attributes are defined to part of the start-tag.

Sounds good to me and is hence also defined for the default namespace.

I would recommend to add an informative note to MDPWS and BICEPS.
NOTE: The part of a QName identifying the namespace (either default or prefixed) used in the either [content](w3.org/TR/REC-xml/#NT-content) or [attribute value](https://www.w3.org/TR/REC-xml/#NT-AttValue) must have been declared in a namespace declaration attribute in either the start-tag of the element where the prefix is used or in an ancestor element.

[Maximilian Pilz]

@schlich09 , unfortunately you have taken the sentence

The Prefix provides the namespace prefix part of the qualified name, and must be associated with a namespace URI reference in a namespace declaration.

out of context. It has to be seen as an additional information for

[Definition:] In XML documents conforming to this specification, some names (constructs corresponding to the nonterminal Name) may be given as qualified names, defined as follows: ...

This references the "Name" definition (to be precise a slight alteration of the definition, but that does not change the issue), which defines a special kind of "Nmtoken". Those are not attribute values or non sub element contents. Thus this does not solve the problem.

Same thing for

Namespace Constraint: Prefix Declared
The namespace prefix, unless it is xml or xmlns, must have been declared in a namespace declaration attribute in either the start-tag of the element where the prefix is used or in an an ancestor element (i.e. an element in whose content the prefixed markup occurs).
The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. The prefix xmlns is used only for namespace bindings and is not itself bound to any namespace name.

, it also applies to elements and attributes, but not necessarily their value or content, especially not to attribute values.

In addition, as @d-gregorczyk already mentioned, this problem has been solved for xml schema to make it possible to use qnames reliably as attribute values to identify types when defining objects in the schema. However this does not extend to non schema xml i.e. other xml documents.

All of this also invalides

...The ·lexical space· of QName is the set of strings that ·match· the QName production of [Namespaces in XML].
Note:The mapping between literals in the ·lexical space· and values in the ·value space· of QName requires a namespace declaration to be in scope for the context in which QName is used.

as an argument on your side, because it references the defintion at https://www.w3.org/TR/1999/REC-xml-names-19990114/#dt-qname, which in return references the Nmtoken Names.

As a conclusion, your suggestion is insufficient due to a namepsace declaration not having to be used for resolving all qnames. It depends on where they occur, even if they occur in the element for which the namespace declaration exists.