This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In Part 1 section 3.4.5.1, it is stated: <quote> [prefix] If the {attribute declaration} has a ·non-absent· {target namespace} N, then a namespace prefix bound to N in the [in-scope namespaces] property of the element information item in the ·post-schema-validation infoset·. If the {attribute declaration}'s {target namespace} is ·absent·, then ·absent·. If more than one prefix is bound to N in the [in-scope namespaces], it is ·implementation-dependent· which of those prefixes is used. </quote> There is a case this does not cover, namely when the attribute declaration has a non-absent target namespace, and no prefix is bound to N in the in-scope namespaces of the instance, either because the target namespace is not declared in the instance, or because it is the default namespace in the instance. In this case I believe the correct action is for an implementation-dependent prefix to be used. This issue is currently being discussed in the JDOM community; when Xerces is used as the schema processor, it generates an Infoset (in the form of a stream of SAX events) in which the attribute information item has a namespace URI but no prefix, and this crashes JDOM (I think it would also crash Saxon). The (lengthy) JDOM thread can be found here: http://markmail.org/message/ufye27danv4myk35
It has also been noted in the JDOM thread that XSD 1.0 is silent on the question of what the [prefix] of the new attribute should be - see section 3.4.5. It has also been pointed out that the Infoset specification (unlike XDM) does allow "synthetic infosets" to be inconsistent, for example by having an attribute that is in a namespace but has no prefix in its name. However, I think it is undesirable that a schema processor should generate an inconsistent Infoset, as the history of this JDOM bug illustrates. One other observation: if we add the rule that in the absence of a namespace binding, the schema processor should invent a prefix, then we should also say that it should construct a namespace information item that binds that prefix to the target namespace.
We need to decide if this should be recast as a 1.0/1.1 bug. At the telcon, discussion came to: w.r.t. 1.1, the case is covered by the statement earlier in SISC Attribute Default Value: "In addition, if necessary ·namespace fixup· is performed on the element information item for the {attribute declaration}'s {target namespace}." and the definition of namespace fixup. w.r.t. 1.0 I believe this is or should be a WONTFIX. We may already have explicitly marked this or a related namespace fixup issue as WONTFIX for 1.0 (we may want to check).
MK: a further clarification is that a 4th case should be added. ...: "if no namespace is declared go see the namespace fix-up rules."
MSM: so for 1.0 it's won't fix, and for 1.1 an editorial fix to say that the namespace fix-up rules apply.
The changes eventually made to the wording of the spec have been recorded in https://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b13750.html (member-accessible link) Since the WG did not want to see the wording again, I'm marking this issue resolved. Michael, as the originator would you please review the wording (which should be included in the status-quo document in a day or so, or can be reviewed in the change record just mentioned) and close the bug if you agree that it's been resolved? Thank you.