Community
Participate
Working Groups
Our current implementation of the QName (de)resolution makes some incorrect assumptions regarding the prefix to namespace mapping. The following would - from my point of view and after studying the relevant W3C recommendations - be the correct resolution procedure. A) Reading: At the moment, our resolution of a QName into an object assumes that the absence of a prefix implies a reference to the local resource. The namespace of a QName without prefix is, however, the default namespace (xmlns="...") [1], if defined (otherwise it has no namespace). The default namespace is not necessarily equal to the target namespace of the BPMN2 document (which defines the namespace of all elements contained in the definitions element). Take for example the following Definitions element: <bpmn2:definitions targetNamespace="urn:this" xmlns="urn:other" xmlns:this="urn:this" xmlns:bpmn2="..."/> Inside this element, the QName "this:id1" would point to a local element contained in this definitions element. "id2" (no prefix) would point to an element in the resource that is associated (by an import element) with the namespace "urn:other". The first would be correctly resolved by our implementation, the latter, however, would not. A special case occurs if no default namespace is defined and a QName has no prefix. In this case, the QName points to an element that is in no namespace [1]. If the containing definitions defines no target namespace, its contained elements reside in "no namespace" as well [2], thus a resolution is possible (even though the BPMN2 is invalid, because targetNamespace is a required attribute of definitions). If it defines a target namespace for its elements, but no default namespace, there is no immediate place available where to look for the prefix-less elements. Possible solutions: (1) treat as invalid, (2) interpret as local reference (implicit default = target namespace), (3) allow imports for "no namespace". B) Writing: Our deresolution from object to QName does not set the default namespace while using unprefixed QNames for local references, so that these QNames could not be resolved if our resolution followed the procedure outlined above. Other tools using a more strict resolution will not find referenced elements, either. We either have to set the default namespace to the target namespace or use a prefix representing the target namespace. An example of a document generated by our serialization: <bpmn2:definitions xmlns:bpmn2="..." targetNamespace="urn:modelA" ...> ...<bpmn2:target>idOfLocalElement</bpmn2:target>... The QName of the target element is intended to point to an element in the same definitions, however, it is not resolvable according to the namespace specification, as no default namespace is defined. An additional attribute xmlns="urn:modelA" is required on the definitions element (or an explicit prefix for this namespace). I'd suggest that our implementation should ... * be able to deserialize all documents with correct prefix-namespace-mappings (currently missing: resolution of prefix-less QNames with default namespace != target namespace) * provide some kind of fallback to resolve (slightly) incorrect serializations (as possibly produced by other tools), for example in the following situations: ** prefix-less QName, no default namespace, but target namespace defined => guess "local reference" (current behaviour, as default ns is ignored) ** prefix-less QName, default namespace defined (!= target ns), but not mapped to a location by an import element => guess "local"?? * serialize correctly: define default namespace, if target namespace is defined. If these suggestions are OK, I'll try to implement the necessary changes. [1] http://www.w3.org/TR/xml-names11/#defaulting [2] http://www.w3.org/TR/xmlschema-1/#cElement_Declarations
I completely agree with all your proposals. I thinks most urgent is the creation of default namespace declaration in case that a targetNamespace is defined.
Fixed in 861e4ace782a2b6f22afc9359de90446b7369990 The resolution behaves as outlined above, including relaxed resolution standards for unprefixed QNames. If the default namespace can not be resolved, the implementation "guesses" that a local reference was meant. For the moment, the detection if a reference is local is somewhat simplistic (direct comparison to path of resource). As I see some other problems with relative vs. local references and import locations, I'll deal with the comparison when handling these problems.