Bug 13750 - Prefixes for defaulted attributes
Summary: Prefixes for defaulted attributes
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: 1.1 only
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: David Ezell
QA Contact: XML Schema comments list
Keywords: resolved
Depends on:
Reported: 2011-08-10 17:15 UTC by Michael Kay
Modified: 2011-12-28 18:16 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Kay 2011-08-10 17:15:14 UTC
In Part 1 section, it is stated:

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.

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
Comment 1 Michael Kay 2011-08-10 21:54:10 UTC
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.
Comment 2 David Ezell 2011-08-12 16:04:48 UTC
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).
Comment 3 David Ezell 2011-10-21 15:56:47 UTC
MK: a further clarification is that a 4th case should be added.
...: "if no namespace is declared go see the namespace fix-up rules."
Comment 4 David Ezell 2011-11-11 16:56:05 UTC
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.
Comment 5 C. M. Sperberg-McQueen 2011-12-28 18:16:57 UTC
The changes eventually made to the wording of the spec have been recorded in 

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