- 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
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.:
<newstd:schemas>
<xsd:schema targetNamespace="one">
...
</xsd:schema>
<xsd:schema targetNamespace="two">
...
</xsd:schema>
</newstd:schemas>
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
helps.
------------------------------------------------------------------
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
Categories:
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 !
Hanna
-----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"/>
</ns1:outer>
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">
<sequence>
<element ref="ns2:inner/>
</sequence>
</element
</schema>
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"
schemaLocation="http://example.org/ns2.xsd">
<element name="ns1:outer">
<sequence>
<element ref="ns2:inner/>
</sequence>
</element
</schema>
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
instance:
<ns1:outer xmlns:ns1="uri1">
<ns2:inner xmlns:ns2="uri2" schemaLocation"uri2
http://example.org/ns2b.xsd">
</ns1:outer>
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"
schemaLocation="http://example.org/ns2.xsd">
<element name="ns1:outer">
<sequence>
<any processContents="lax">
</sequence>
</element
</schema>
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