OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: LC-117: Locating schema resources

[ Lists Home | Date Index | Thread Index ]
  • From: ht@cogsci.ed.ac.uk (Henry S. Thompson)
  • To: Curt Arnold <CurtA@techie.com>
  • Date: Sat, 23 Sep 2000 11:51:22 +0100

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"
. . .

> >
> > 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.

> 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)


> 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.

> 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.

  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/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS