This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 4.3.2 of the structures spec has "xsi:schemaLocation and xsi:noNamespaceSchemaLocation [attributes] can occur on any element. However, it is an error if such an attribute occurs after the first appearance of an element or attribute information item within an element information item initially ·validated· whose [namespace name] it addresses." It's not clear what value this rule brings, but it does prohibit certain usage of schema (where different parts of a document uses different portions of components from the same namespace) and certain schema processing modes (where schemas are pre-built and cached and xsi: schema location attributes are ignored).
> It's not clear what value this rule brings, but it > does prohibit certain usage of schema (where > different parts of a document uses different > portions of components from the same namespace) > and certain schema processing modes (where schemas > are pre-built and cached and xsi: schema location > attributes are ignored). As I recall, the reasoning is along these lines: We want to facilitate the construction of streaming processors. If we allow schemaLocations after first use of the namespace, then either a streaming processor is forced to backtrack and undo any results that may have been affected by newly acquired components, or to be deficient as seen from the outside, in that there are legal schema/instance pairs that it cannot handle. In order to avoid having streaming processors appear to be deficient in such a way, we restrict use of the schemaLocation mechanisms to patterns that do not subvert streaming. Note that support of such late arriving schemaLocations might be complex even for more traditional processors. Imagine, for example, a schemaLocation on the last element of a document, with a definition for a namespace used early. To support this, the processor would effectively have to do a prepass on the whole document to look for such schemaLocations, then assemble a schema, then validate. Of course, this is just another way of saying that even processors that are willing to buffer an entire input document may find it convenient to do some things in a streaming mode, so maybe it's not a completely separate argument. I can see that this rule is not the only sensible choice to make, but it was a decision made back in the Schema 1.0 days with (I think) pretty full awareness of the tradeoffs. I'm not aware of any new information that would merit reconsidering now, or why this is prioritized high. Furthermore, even if the decision is suboptimal, changing it would raise questions for those who want to adapt existing 1.0 processors as the basis for their 1.1 implementations. They would have to revisit their current code that throws errors, decide what to do, perhaps change documentation, etc. I'm not convincee we made the perfect decision in 1.0, but I feel fairly strongly that we should not change it now. Noah
Adopted a proposal at April 27, 2007 telecon to *not* treat this case as an error.
The proposal adopted by the Working Group has now been integrated into the status quo documents on the server; accordingly, I'm changing the status to 'RESOLVED'.