Re: LC-117: Locating schema resources

Since all the addressee's (Noah Mendelsohn and the XML comments list)
don't have the previous message, I've quoted all of Henry's previous
message.

"Henry S. Thompson" wrote:
> 
> Curt Arnold <CurtA@techie.com> writes:
> 
> > This is in response to
> > http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000JulSep/0209.
> > html on XML Schema last call issue LC-117
> > http://www.w3.org/2000/05/12-xmlschema-lcissues#locating-schema-resources.
> >
> > Noah Mendelsohn wrote:
> >
> > > >>  there is not a mechanism to identify a schema
> > > >>  resource to be used to validate an XML 1.0
> > > >>  (pre-namespace) compatible document.
> > >
> > > In fact, as described in section 6.3.2 of the
> > > structures specification, the noNamespaceSchemaLocation
> > > attribute is provided for exactly this purpose.
> >
> > Using xsi:noNamespaceSchemaLocation to specify a schema location
> > hint would cause the document to be invalid according to a
> > pre-existing DTD.  The only way that I could see that a document
> > could declare that it adheres to a specific schema while retaining
> > validity to an existing DTD would be through use of a processing
> > instruction.
> 
> Not so.  Suppose the DTD is at foo.dtd, and the doc't element is baz.
> Then simply write
> 
> <?xml version='1.0'?>
> <!DOCTYPE baz SYSTEM "foo.dtd" [
> <!ATTLIST baz xmlns:xsi CDATA #IMPLIED
>                xsi:noNamespaceSchemaLocation CDATA #IMPLIED>
> ]>
> <baz xmlns:xsi="http://www.w3.org/2000/10/XMLSchema"
>      xsi:noNamespaceSchemaLocation="http://www.example.com/MySchemas/foo.xsd">
> . . .
> </baz>

You are right on this one (actually you are right on all of them), I
should not write comments after 3 AM.


> 
> > >
> > > There is no need to explicitly import (since you are
> > > talking about multiple namespaces, I presume you meant
> > > import rather than include) namespace B into the schema
> > > for namespace A, except in the case where constructions
> > > from B are explicitly and directly used in creating
> > > declarations for A.
> >
> > I did mean import (sorry) and I was precisely talking about instances
> > where
> > constructions from multiple namespaces are used in creating a schema
> > resource that combines elements from multiple namespaces.
> >
> > For example, if I have an "http://www.example.com/namespace/automobile"
> > namespace that imports distinct namespaces for major subsystems
> > ("..drivetrain", "..engine", "..interior", "..frame", "..suspension",
> > "..tires", "..transport", "..finance", etc) plus generic namespaces like
> > XHTML and uses elements from these distinct namespaces to describe the
> > overall picture of a car.  Each individual namespace may be owned by a
> > different organization (either an internal division or WG or an external
> > organization) that may independently revised.
> >
> > When I assume version "1.0" of the schema for "../automobile", I specify
> > through my <xsd:import>'s specific hints that indicate that version
> > "1.0" of
> > this namespace uses elements from version "1.15" of "drivetrain", "1.7"
> > of
> > "engine", "1.3" of interior, etc.
> >
> > <xsd:schema
> > targetNamespace="http://www.example.com/namespace/automobile">
> >     <xsd:import namespace="http://www.example.com/namespace/drivetrain"
> > schemaLocation="http://www.example.com/schemas/drivetrain/115"/>
> >     <xsd:import.../>
> >     <xsd:import.../>
> >     <xsd:element name="automobile">
> >         <xsd:complexType>
> >             <xsd:element ref="drivetrain:transmission"/>
> >         </xsd:complexType>
> >     </xsd:element>
> > </xsd:schema>
> >
> > For me to use schemaLocation to specify that this schema resource should
> > be
> > used to validate its 15 or so imported namespaces, I have to do
> > something
> > like:
> >
> > <automobile xmlns="http://www.example.com/namespace/automobile"
> >
> > xmlns:drivetrain="http://www.example.com/namespace/drivetrain"
> >
> > xmlns:engine="http://www.example.com/namespace/engine"
> >
> > xsi:schemaLocation="http://www.example.com/namespace/automobile
> > http://www.example.com/schema/automobile10.xsd
> > http://www.example.com/namespace/drivertrain
> > http://www.example.com/schema/automobile10.xsd
> > http://www.example.com/namespace/engine
> > http://www.example.com/schema/automobile10.xsd
> > ....
> > >
> 
> Any one hint is sufficient -- once you've got a schema corresponding
> to a schema document (e.g. http://www.example.com/schema/automobile10.xsd)
> you've got all the components defined/declared _or imported/included_
> in it.
> 

Providing an xsi:schemaLocation for the first namespace encountered that
references a schema resource that imports the other namespaces used in
the instance should totally fulfill the processor's schema information
requirements.  It is not painfully obvious however, and probably warrant
a mention in the Primer and a careful watch that the parser
implementations support it.


> > The tension comes from a dual nature of schemaLocation.  It tries to
> > act both as a retrieval location for a resource (a file:// URL that
> > an XML editor validates during development)
> 
> yes
> 
> > and an assertion of
> > conformance to a known universally identified schema resource (a URN
> > or http:// URL that would rarely be dereferenced) that a server
> > would typically ignore before validating with a schema resource of
> > its choosing.
> 
> no, that's the namespace URI, if you choose to use it that way.

The namespace URI is not sufficient in all scenarios.  There are many
cases were it would be advantageous for a document to assert that it
conforms to a particular schema for a namespace.  For example, a server
may know a schema for version 1.0 of a namespace and have schema that
has been designed (through pervasive use of <xsd:any>'s and
<xsd:anyAttribute>'s) to accept not-yet-developed versions of the
schema.  If the server can ascertain that the document conforms to
version 1.0, then it can use the more compact schema.

The problem was that the "hint" nature of xsi:schemaLocation looked like
a way to communicate this information, that a particular
xsi:schemaLocation hint could indicate version 1.0 of a schema and a
different hint could indicate an upward compatible schema.  This caused
the tension that I described of whether schemaLocation was acting as a
resource of as an abstract identifier.

After some thought, the solution to the dilemma is to communicate that
"version" information, when necessary, through a different mechanism. 
It seems best to me that this information be expressed in the target
namespace.  If I have a messaging namespace, I could say that the
<message> should have a schemaVersion attribute that could be used (in
an application-specific manner) to determine which particular schema
should be used.  For example:

<message xmlns="http://www.example.com/namespace/messaging" 
         schemaVersion="1.0" 
         xsi:schemaLocation="file://c|/schemas/messaging.xsd">
>

Though this requires no support in XML Schema, use of xsi:schemaLocation
is such an enticing mechanism that an explicit discouragement of that
use and a description of alternative approachs could be beneficial.


> 
> > Based on your message, I going state that I'm not satisfied with the
> > proposed resolution (basically to leave schema resource location
> > substantially unchanged with the exception of LC-116) in that there
> > are substantial use cases (XML 1.0 compatible documents and
> > documents where a large number of namespaces are governed by a small
> > set of schema resources) where the suggested mechanism of asserting
> > schema conformance is unsatisfactory to the point that alternative
> > solutions will be used.
> 
> I hope I've addressed both these concerns above.
> 
> 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/

Thanks, Henry.  I look forward to reading the new schema draft and
appreciate all the hard work.  Each of these points might benefit from
some coverage in the Primer and/or Structures document, however it
appears that my concerns on this issue are appropriately addressed.

Received on Sunday, 24 September 2000 00:07:59 UTC