W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2003

RE: XML schema validation and namespaces

From: <noah_mendelsohn@us.ibm.com>
Date: Thu, 30 Jan 2003 08:47:12 -0500
To: "Hanna" <lhnhanna@hotmail.com>
Cc: lhnhanna@hotmail.com, xmlschema-dev@w3.org
Message-ID: <OFA61D26C6.DB35C032-ON85256CBE.004B042B@lotus.com>

Thank you for taking the trouble to notice my earlier note on this 
subject.  I think your current question boils down to:

Q. Is there any way to provide schema declarations for elements, 
attributes etc. that are in more than one namespace, using just a single 
XML (I.e. XSD file)?
A. Short answer:  no.   Longer answer: yes, in principle, but not in a way 
that has been standardized

The schema recommendation carefully separates the definition of the 
standard for the core capabilities of the language from the definition of 
the syntax of the schema documents (informally called .xsd files) that are 
used to write down those definitions.  In principle, a processor can 
conform to just the former, and get its definitions using more or less 
arbitrary means.  In practice, most processors I'm aware of support only 
.xsd (a reasonable choice for now), and by definition an .xsd file covers 
at most one namespace.  Indeed, even the .xsd format itself (to adopt your 
terminology) is specified at the Infoset (abstract elements and attributes 
level.)  A third level of conformance is associated with retrieval of such 
representations in the form of XML documents using URIs and the mechanisms 
of the web.  That's a round about way of saying that there is a 
conformance level governing what most processors today do:  get each .xsd 
document from a separate "web file".

Nothing in the recommendation prevents anyone else from establishing a 
standard for new representations, or from packaging multiple .xsd infosets 
 together.  E.g.:

        <xsd:schema targetNamespace="one">
        <xsd:schema targetNamespace="two">

This would be just one way to do it.  As of now, I'm not aware of any such 
standard, and therefore not aware of any processors that provide this 
capability, but the recommendation leaves room for someone to standardize 
this usage.

Note that this flexibility in the schema recommendation is used in some 
other contexts.  WSDL, the description language for SOAP and Web Services, 
embeds fragments of schemas within WSDL files using the technique 
described above.  There are WSDL processors that extract these schemas and 
provide them to XML processors for use in validation.

I'm not sure this is the answer you were hoping for, but I do hope it 

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

"Hanna" <lhnhanna@hotmail.com>
Sent by: xmlschema-dev-request@w3.org
01/29/03 10:44 PM

        To:     <xmlschema-dev@w3.org>, <lhnhanna@hotmail.com>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: XML schema validation and namespaces

Dear all, 
      if i don't have xsd file to be refereced but i want to deal with 
multiple namspaces in schema. How can it be done? 
In fact, can one schema handle multiple namespace without ref or import?
    Please help !
-----Original Message-----
From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
Sent: Friday, September 06, 2002 8:20 AM
To: Sanjay Dahiya, Noida
Cc: xmlschema-dev@w3.org
Subject: Re: XML schema validation and namespaces

Well, I can give you some general idea of how things work.  First of all, 
you're right, there are namespaces tbat you bump into in schema documents, 

namespaces that the instance might use, and a set of rules that have to 
keep straight how these all work together.  The schema design goes to 
great length to cover these, and it probably gives more flexibility than 
you'd notice at first.

A schema document can use the <import> construction to refer to other 
schema definitions for other namespaces.  Optionally, the import can 
supply a schemaLocation hint (and it's only a hint!) that the process MAY 
choose to follow to look for the schema definitions for that other 
namespace.  Alternatively, the schema processor can use some other means 
to figure out what schema definitions to use for that other namespace 
(maybe it takes command line options, has an API, builds in definitions 
for certain namespaces, etc.)

So, what happens if an instance document uses a namespace in some element 
in the middle of content:

        <ns1:outer xmlns:ns1="uri1">
                <ns2:inner xmlns:ns2="uri2"/>

What are the possibilities for where we get the definitions to validate 
ns2:inner (presuming we had a schema for ns1?)  Well, I'm too lazy to type 

all the schemas exactly correctly, but if the schema for ns1 says roughly

        <schema targetNamespace="ur1" xmlns:ns1="uri1" xmlns:ns2="uri2">
                <import namespace="ur12">

                <element name="ns1:outer">
                                <element ref="ns2:inner/>

then the processor will go looking for some schema document (or other 
source of definitions) for ns2:inner.  Exactly how is, as described above, 

up to the processor.  With:

        <schema targetNamespace="ur1" xmlns:ns1="uri1" xmlns:ns2="uri2">
                <import namespace="ur12" 

                <element name="ns1:outer">
                                <element ref="ns2:inner/>

then the processor MAY chose to get those definitions from 
http://example.org/ns2.xsd.  Another way it might get the hint is from the 

        <ns1:outer xmlns:ns1="uri1">
                <ns2:inner xmlns:ns2="uri2" schemaLocation"uri2 

Again, it's a hint.  The processor can honor the one in the import, in the 

instance, neither, etc.

Now consider:

        <schema targetNamespace="ur1" xmlns:ns1="uri1" xmlns:ns2="uri2">
                <import namespace="ur12" 

                <element name="ns1:outer">
                                <any processContents="lax">

This says that outer can have most any contents.  Does ns2:inner get 
validated?  Well, if the processor choses to find a schema, perhaps from 
one of the schemaLocation hints, then the inner element does get 
validated.  "Lax" says: validate if you have an element declaration, 
otherwise don't worry about it.  "strict" (instead of lax) means "you 
better have an element declaration, if not fail".  "skip" means don't 
validate the inner element even if you could.

To really understand this, you should find a good tutorial on schema, or 
maybe even do the hard work of reading the spec (it is hard in this area.) 

I hope you can see that the design provides quite a bit of power for 
dealing with the situations you've raised.   Many of them do arise in 
various uses of XML.  I hope this is helpful.
Received on Thursday, 30 January 2003 09:26:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:55:59 UTC