- From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
- Date: 28 Sep 2001 08:29:13 +0100
- To: "Aung Aung" <aaung@microsoft.com>
- Cc: <xmlschema-dev@w3.org>, "Derek Denny-Brown" <derekdb@microsoft.com>, "Yan Leshinsky" <yanl@microsoft.com>, "Huseyin Ulger" <ulger@microsoft.com>, "David Brown (WEBDATA)" <davebrow@microsoft.com>, "Priya Lakshminarayanan" <priyal@microsoft.com>, "Peter Burzynski" <peterbu@microsoft.com>
"Aung Aung" <aaung@microsoft.com> writes: > Thanks for the quick response. Forgive me for persisting with this, I am > not sure your answer my quesetion, maybe my question is not clear, I > will attempt to make it clearer below. I have 2 issues below. (A). the > existing issue and (B). a new question raised from the existing issue. > > Issue (A): I am confused....I do now see anywhere in the XSD spec that > allows such inheritance of namespace declaration from includer XSD to > includee XSD. Clauses 2.3 and 3.2 of Inclusion Constraint Semantics [1] provide for the so-called 'chameleon' include. > Lets put a prefix for the namespace declaration in a.xsd. This can _never_ make any difference -- each schema document is interpreted per the prefixing/qualification rules, and the resulting expanded names (which we write for illustration as {ns or None}local) are the basis for all further computation. > Should the following still valid? > a.xsd~~~~~~~~~~ the targetNamespace 'foo' is used to qualified all the > global element and attributes in the including and includee XSD(s). > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" > targetNamespace="foo" > xmlns:a="foo"> Note the above declaration is irrelevant and serves no purpose, as there are no a: prefixed names in this document > <xsd:include schemaLocation="b.xsd" /> > <xsd:include schemaLocation="c.xsd" /> > </xsd:schema> > b.xsd~~~~~~~~~~~ Which one of the following XSD is valid for a.xsd? > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> > <xsd:element name="foo" type="foo"/> > </xsd:schema> > > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" > xmlns:a="foo"> > <xsd:element name="foo" type="a:foo"/> > </xsd:schema> > > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> > <xsd:element name="foo" type="a:foo"/> > </xsd:schema> This is broken, because there is no binding for the 'a' prefix. The other two are OK, although the second is odd, in that it works _only_ because it and c.xsd are being included into a schema with target namespace 'foo' -- if included in a schema doc't with any _other_ target namespace, this will not work, because {foo}:foo will _not_ be converted. > c.xsd~~~~~~~~~~~ the type 'foo' will be converted to [foo]:foo > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> > <xsd:simpleType name="foo"> > <xsd:restriction base="xsd:string"> > <xsd:enumeration value="test"/> > </xsd:restriction> > </xsd:simpleType> > </xsd:schema> > > > Issue (B). in light of this issue we are discussing, there is another > issue been raised by Derek... > In XSD spec 4.2.1 said the following: > Schema Representation Constraint: Inclusion Constraints and Semantics > > In addition to the conditions imposed on <include> element information > items by the schema for schemas, all of the following must be true: > 1 If the *actual value* of the schemaLocation [attribute] successfully > resolves one of the following must be true: > 1.1 It resolves to (a fragment of) a resource which is an XML document > (of type application/xml or text/xml with an XML declaration for > preference, but this is not required), which in turn corresponds to a > <schema> element information item in a well-formed information set, > which in turn corresponds to a valid schema. > 1.2 It resolves to a <schema> element information item in a > well-formed information set, which in turn corresponds to a valid > schema. > > Reading from it, the b.xsd from my example which is included in the > a.xsd is NOT allowed, it does not have a well-formed information set > which in turn corresponds to a valid schema. > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> > <xsd:element name="foo" type="foo"/> > </xsd:schema> This is a perfectly well-formed XML document, so it has an information set. It also corresponds to a well-formed schema. It has a dangling reference, but that's explicitly allowed for. > Should it work? Where is the type="foo" resolved to? Doesn't b.xsd also > needs to explicitly have <include schemaLocation="c.xsd"/> ? Remember that references are explictly lazy, that is, dangling references are not an error until they _need_ to be resolved because some aspect of an _instance_ being validated requires them. ht [1] http://www.w3.org/TR/xmlschema-1/#src-include -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh W3C Fellow 1999--2001, part-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/
Received on Friday, 28 September 2001 03:28:34 UTC