Yes, that all makes sense. I still believe, in addition, that the ability to
locate a schema for a namespace based on an import in another schema is
implementation-dependent. A processor is not required to do anything with
the schemaLocation in an import, including remember it.
On the other hand, an implementation _could_ work by first fetching all
schemas applicable to a node, then using the information from these schemas
to locate a schema for the namespace of the root node. This would make the
original example work, but it would again be implementation-dependent.
In another circumstance, one might be expecting lax validation based on a
schema locatable only through an import in another schema, but if the
processor is unable to locate the schema in this way it will quietly accept
anything from the namespace. You think you have validation, but you don't.
I think the following is true: The only guaranteed path to successful
validation across implementations is to specify a schemaLocation for each
namespace in the document you expect to be subject to strict or lax
validation.
Bob
----- Original Message -----
From: "Jeff Greif" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 26, 2003 11:18 AM
Subject: Re: Schema validation using multiple schemas
> Here are the general principles:
> 1. The schema processor must be able to obtain the location of all
schemas
> it must use to validate the instance document and the schemas used to
> validate that document (if this level of validation is desired.)
> 2. **While reading a schema** it can use that schema's imports to find
> schemas on which the first schemas depend, and so on recursively.
> 3. It must be able to find the schema for the namespace of the root
> element of an instance document, either from a schema location in the
> instance document or from some other external means (the
> externalSchemaLocations property of the Xerces parser, or an entity
> resolver, for instance).
> 4 Having found the schema for the root element, typically any others
> needed will be found via import or include elements or schema location
> settings in the document or parser configuration.
>
> In your case, schema1 imported schema2, schema2 contained the definition
of
> the root element of the document, and you specified schema1's location in
> the document. Since schema1's namespace was irrelevant to the validation
of
> the root element, there was no reason for xerces to look inside it to see
if
> it indicated where to find schema2.
>
> The short answer is that the processor needs to be able to find the schema
> for the root element of the document. If you have several kinds of
> documents, with root elements in different schemas, you need to be able
> specify the correct schema location for each one. If the schema for the
> root element depends on others, they must be specified in imports, and the
> locations specified somehow (import or otherwise). If any schema allows
> wildcards or anyType, or element substitutions, or derived datatypes from
> other namespaces, the locations of the schemas for those namespaces
actually
> referenced in the instance document must be available to the
> parser/validator.
>
> Jeff
>
> Jeff
> ----- Original Message -----
> From: "Adachi Seiichi" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, August 26, 2003 5:15 AM
> Subject: Re: Schema validation using multiple schemas
>
>
> > Bob, Jeff,
> >
> > Thank you for your replies.
> >
> > I have 2 questions.
> >
> > 1. I understand that there may be a need to specify schema#2 in the
> > xsi:SchemaLocation of the XML file. However, for a more complex XML
> > schema, wouldn't this mean that you would have to specify all the
> > schemas in each XML file?
> >
> > Yes, this problem can be resolved if you specify the location of
schema#2
> > in
> > the XML file. However, the XML schemas for my application will be more
> > complex and I do not want to specify all the schemas that are involved.
> >
> > I am not that familiar with XML but it was my understanding that when
> > creating an XML file, you do not need to specify the location of all the
> > schema files that are declared as namespaces inside the XML file, if
> > they are defined (imported) by the schemas that are specified in the
> > xsi:schemaLocation of the XML file. At least, that is what it said in
> > the 2 XML Schema books I have here. (Sorry, they are in Japanese)
> > I guess this maybe wrong. To confirm the specification on
> > <xsi:schemaLocation> and <xsd:import> when using multiple namespaces, I
> > have been looking at the w3c documents and searching the web, but have
> > not found a clear answer on this topic. Is this specified somewhere?
> >
> > 2. This relates to question#1, but Xerces-J 2.5.0 is able to
> > resolve the location of imported schema if it is not the root element.
> > For example :
> >
> > test2.xml
> > ---------
> > <book xmlns='http://foo.com/namespace3'
> > xmlns:ns4='http://foo.com/namespace4'
> > xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
> > xsi:schemaLocation='http://foo.com/namespace3 ns3.xsd'>
> > <ns4:chapter>sample XML file</ns4:chapter>
> > </book>
> >
> > ns3.xsd
> > -------
> > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > targetNamespace="http://foo.com/namespace3"
> > xmlns="http://foo.com/namespace3"
> > xmlns:ns4="http://foo.com/namespace4"
> > elementFormDefault="qualified">
> >
> > <xsd:import namespace="http://foo.com/namespace4"
> > schemaLocation="ns4.xsd" />
> >
> > <xsd:element name="book">
> > <xsd:complexType>
> > <xsd:sequence>
> > <xsd:element ref="ns4:chapter"/>
> > </xsd:sequence>
> > </xsd:complexType>
> > </xsd:element>
> >
> > </xsd:schema>
> >
> > ns4.xsd
> > -------
> > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > targetNamespace="http://foo.com/namespace4"
> > xmlns="http://foo.com/namespace4"
> > elementFormDefault="qualified">
> >
> > <xsd:element name="chapter" type="xsd:string"/>
> >
> > </xsd:schema>
> >
> > Since this file is validated correctly, I had assumed Xerces-J 2.5.0
> > supports these kind of files. Is there any possibility that unable to
> > resolve it in the case of the root element is a bug? (I know they are
> > implemented differently but just as a note, Xerces-C 2.3.0 did not
> > return any errors.) Or is this strictly an implementation dependent
> matter?
> >
> > Thanks,
> >
> > Seiichi
> >
> >
> >
> > >From: "Jeff Greif" <[EMAIL PROTECTED]>
> > >Reply-To: [EMAIL PROTECTED]
> > >To: <[EMAIL PROTECTED]>
> > >Subject: Re: Schema validation using multiple schemas
> > >Date: Mon, 25 Aug 2003 06:51:45 -0700
> > >
> > >Probably xerces proceeds like this:
> > >
> > >Xerces must be able to directly locate the schema for the namespace of
> the
> > >root element. It does not read schema#1 (for a seemingly irrelevant
> > >namespace) in the hopes of finding the location of schema#2. If
schema
> > #1
> > >is in the schemaLocation attribute of the instance document, it should
> > work.
> > >You can include both schemas there if you choose.
> > >
> > >This is not redundant with the import element in schema#1. That import
> is
> > >required in order to make it legal to refer in schema#1 to items from
> > >schema#2.
> > >
> > >Jeff
> > >
> > >
> > >----- Original Message -----
> > >From: "Adachi Seiichi" <[EMAIL PROTECTED]>
> > >To: <[EMAIL PROTECTED]>
> > >Sent: Monday, August 25, 2003 1:39 AM
> > >Subject: Schema validation using multiple schemas
> > >
> > >
> > > > Hi All,
> > > >
> > > > I am trying to validate an xml file using multiple schema files
using
> > > > Xerces-J 2.5.0. The xml file specifies the location of schema#1
using
> > > > schemaLocation. Inside of schema#1, schema#2 is specified using
> > > > xsd:import. I get an error when the root element of the xml file is
> an
> > > > element defined in schema#2.
> > > >
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> > _________________________________________________________________
> > 自宅の PC で英語力をアップ MSN 英会話
> > http://englishtown.msn.co.jp/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
