- From: Aung Aung <aaung@microsoft.com>
- Date: Thu, 27 Sep 2001 14:38:58 -0700
- To: "Henry S. Thompson" <ht@cogsci.ed.ac.uk>
- 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>
Henry, 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. Lets put a prefix for the namespace declaration in a.xsd. 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"> <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> 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> Should it work? Where is the type="foo" resolved to? Doesn't b.xsd also needs to explicitly have <include schemaLocation="c.xsd"/> ? *Ps* These are very sensitive issues where all must be clearly and specifically clarify with example. Different implementation of the above may arise in servior divergance in XSD usage. Regards, -Aung -----Original Message----- From: Henry S. Thompson [mailto:ht@cogsci.ed.ac.uk] Sent: Thursday, September 27, 2001 12:12 PM To: Aung Aung Cc: xmlschema-dev@w3.org Subject: Re: Default namespaces and <includes> "Aung Aung" <aaung@microsoft.com> writes: > >So since valid includes must be from a schema doc't to a schema doc't > >which _share_ a targetNamespace value, references in the includer to > >components defined in the includee look just like references in the > >includer to itself. No transfer of namespace bindings, which are > >purely a matter for the XML Namespaces REC, is implied or required. > > Henry, Your answer does not quite answer the question Mike is asking. > How about references in the includee to components defined a different > includee?? > > The example of the issue is below. > Questions: > 1. should the "a.xsd" be valid XSD? please note that type="foo" in > b.xsd is not qualified (there is no namespace declared for it). > > > a.xsd~~~~~~~~~~ > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" > targetNamespace="foo" xmlns="foo"> > <xsd:include schemaLocation="b.xsd" /> > <xsd:include schemaLocation="c.xsd" /> > </xsd:schema> > > b.xsd~~~~~~~~~~~ > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> > <xsd:element name="foo" type="foo"/> > </xsd:schema> > <!-- > Q?: Does "b.xsd" requires namespace declaration > xmlns="foo" > --> This _is_ answered in my reply. type='foo' is interpreted in the context of b.xsd as an XML document, in which there is no default NS declaration, so this is a reference to {None}foo _as it stands_. > c.xsd~~~~~~~~~~~ > <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> And this defines {None}foo, since there is no target namespace. So despite the fact that this _is_ an example of chameleon include, which was explicitly not addressed by my reply, including both these files will always work: a) They are included into a schema which itself has no target namespace, in which case they are unchanged and {None}foo will match {None}foo b) They are chameleon included into a schema which does have a target namespace, in which case both the ref and the def will be converted to {[tns]}foo. ht -- 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 Thursday, 27 September 2001 17:39:29 UTC