This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4057 - elemZ006: referencing a namespace that has not been imported
Summary: elemZ006: referencing a namespace that has not been imported
Status: RESOLVED FIXED
Alias: None
Product: XML Schema Test Suite
Classification: Unclassified
Component: Microsoft tests (show other bugs)
Version: 2006-11-06
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Henry S. Thompson
QA Contact: XML Schema Test Suite mailing list
URL:
Whiteboard: metadata updated 2008-11-26 (new tools)
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-09 17:32 UTC by Michael Kay
Modified: 2008-11-26 15:46 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2006-12-09 17:32:22 UTC
In the Microsoft Element test set, test elemZ006, the metadata has the comment:

xsd: [import] it is invalid to reference from a schema that is not directly imported.

and the schema does indeed appear to exhibit this invalidity; however the expected result is given as "valid".
Comment 1 Michael Kay 2006-12-09 18:04:58 UTC
The same problem applies to elemZ007. In this case

elemZ007.xsd includes elemZ007_a.xsd
elemZ007_a.xsd imports elemZ007_b.xsd

and elemZ007.xsd contains a reference to a component in the namespace of elemZ007_b. I believe this is invalid, on the grounds that

(a) in the specification of xs:import, it is clear that the effect is local to a schema document

(b) in the specification of xs:include, it is clear that the effect is to include schema components defined in the included schema document, but not to inherit the effects of declarations such as xs:import that do not themselves result in construction of schema components.

To be fair, the specification is fuzzy in this area. Although it says that xs:import enables reference to components across namespaces, it's hard to find a definitive statement that the absence of an xs:import disables it, or causes the schema to be invalid; indeed, the sentence in 4.2.1 "During schema construction, implementations must retain ·QName· values for such references, in case an appropriately-named component becomes available to discharge the reference by the time it is actually needed." could be taken as making this test case valid. But if that's the correct interpretation, then it's hard to see why the description of xs:import in 4.2.3 repeatedly maintains that its scope is confined to the containing schema document.

So perhaps this bug report should be taken as a request to the WG to clarify the spec (something that is long overdue).
Comment 2 Michael Kay 2006-12-13 18:46:03 UTC
Also applies to test group addB191 in the Microsoft/Additional test set.
Comment 3 Michael Kay 2007-01-02 16:31:04 UTC
Also affects schG9 in the Microsoft "schema" test set.
Comment 4 Michael Kay 2007-01-02 18:27:01 UTC
Also affects

   <test group="schZ004" name="schZ004"/>
   <test group="schZ005" name="schZ005"/>

in the Microsoft "schema" test set.
Comment 5 Michael Kay 2007-01-03 17:55:29 UTC
Also affects test idC019 in the Microsoft identityConstraint test set (the schema idC019.xsd imports idC017a.xsd, which on line 9 contains a keyref pointing to a key defined in idC019.xsd; but the (no-)namespace of idC019.xsd is not imported into idC017a.xsd).
Comment 6 Zafar Abbas 2007-01-29 22:45:15 UTC
Agreed that the expected outcome of this test should be invalid. We are
following up with the WG to determine the process of updating the test suite.
Comment 7 Michael Kay 2008-06-21 15:53:19 UTC
Noted that there is a rule in "Schema Representation Constraint: QName resolution (Schema Document)" that the namespace used in a QName must be imported. However the consequence of failing to import it is that the QName doesn't resolve, and this isn't necessarily a fatal error. So we get into some murky areas of the spec here.

Bug #5779 has been raised against the spec.

The decision on this bug is that we consider these schemas to be invalid.