This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The following test: <test group="addB156" name="addB156.i"/> expects the instance document to be invalid on the basis of the statement in Part 1 section 4.3.2 list item 4: "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." However, Schema Representation Constraint: Schema Document Location Strategy list item 1 says that the processor has the option to "Do nothing, for instance because a schema containing components for the given namespace name is already known to be available". [It's odd that this is a schema representation constraint as it depends on the instance document, but that's another question] It seems to me that it is therefore legitimate for the processor to ignore the second xsi:schemaLocation attribute rather than raising a validity error.
This affects tests addB155 through addB169. On the other hand, if it is accepted that processors MUST report 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" then I would expect test <test group="addB163" name="addB163.v"/> to report this error, in respect of the element <c xsi:schemaLocation="foo test93490_1.xsd" /> The only reason why processors might report an error for other cases but not for this one is that on this occasion the schema is not required to validate any elements; but there's nothing in the spec that says the error disappears if the schema is not needed.
This bug report partially duplicates bug #4078
The only reason the Microsoft interpretation chose to do nothing in the case referenced by test group addB163 is because the schemaLocation hint in question occurs on a laxly validated element for which no schema declaration can be looked up. This is just a design decision and not following any explicit rule in the spec.
WG discovered overlap with bug 4078, but we need to investigate whether we've done everything correcly. Action to HT.
Some time ago (too long) I took an action to examine this bug and report back on the current state of the test cases and their interaction with Mary Holstege's recommendations regarding schemaLocation indications. I have now done so. In all of the instance tests listed, the testGroup has no record of the schema documents involved, so (assuming the WG adopts or has already adopted MH's recommendations) all of these test groups will need to add a schema test listing the schema documents involved in the instance test. In some of the tests (perhaps all the ones where it's appropriate; I haven't reviewed the materials in enough detail to know), the current test suite has two 'expect' elements, one with version '1.0' and one with version '1.1', with different results (valid and invalid) reflecting the change in 1.1 that removes the prohibition on multiple schemaLocatiion hints for the same namespace on different elements. In all of these cases, the document will be valid in XSD 1.1 only if the processor is following schema location hints in the instance; if the processor ignores such hints, the expected result of the test is not 'valid' but 'notKnown'. So for test addB156.i, for example, the current <expected validity="invalid" version="1.0"/> <expected validity="valid" version="1.1"/> should be replaced by <expected validity="invalid" version="1.0"/> <expected validity="valid" version="1.1 instance-schema-loc-follow"/> <expected validity="notKnown" version="1.0 instance-schema-loc-ignore"/> (In passing, I note that this case illustrates why the expected/@version attribute has an implicit AND among its tokens, rather than an implicit OR.) Similar changes are needed in several other cases. Finally, the original description of the bug focuses in test addB156.i, where the current metadata says that for 1.0 the expected result is 'valid'. In considering bug 4078, however, the WG agreed with the argument that the 1.0 spec is currently contradictory with respect to cases like this, and opened bug 9158 as a way of resolving the issue. So for test addB156.i (and possibly others mentioned here), the expected result for 1.0 should not be 'valid' but 'indeterminate'.
In comment 5, the suggestion <expected validity="notKnown" version="1.0 instance-schema-loc-ignore"/> is a typographic error for <expected validity="notKnown" version="1.1 instance-schema-loc-ignore"/> In 1.0 the case is indeterminate regardless of whether schema location hints in the instance are followed or ignored; it is only in 1.1. that the follow/ignore distinction produces different results. Sorry.
*** Bug 15676 has been marked as a duplicate of this bug. ***