- From: <Noah_Mendelsohn@lotus.com>
- Date: Tue, 4 Jan 2000 11:10:23 -0500
- To: "Roger L. Costello" <costello@mitre.org>
- Cc: costello@mitre.org, jcs@mitre.org, msc@mitre.org, www-xml-schema-comments@w3c.org, xml-dev@ic.ac.uk
You are very much on the right track, but there are a few details that
should be clarified:
Case 1:
-------
>> Thus, for this case the value of
>> schemaLocation is:
schemaLocation="urn:person-schema
urn:person-schema/person-schema.xsd"
>> A Schema-validating parser will use the URI to fetch the schema
>> document, and then will verify that the targetNamespace value matches
>> the namespace in schemaLocation.
Here there is a subtlety, because schemaLocation is a hint. The correct
statement would be:
"A Schema-validating parser that honors schemaLocation will use the URI to
fetch the schema
document, and then will verify that the targetNamespace value matches the
namespace in schemaLocation."
Let me attempt to rephrase what Andrew described in his note: the choice
of which schema to use ultimately lies with the consumer. If you as a
consumer wish to rely on the schemaLocation idiom, then you should
purchase/use processors that will honor it for you. The reason that some
other processors might not provide that service for you, is that they are
designed to run in environments where it is impractical or undesirable to
allow the document author to force reference to end use of some particular
schema document. The schemas working draft is designed to allow both
these types of processors to formally claim conformance with the
specification, while insuring interoperability for those processors that
you choose to honor the attribute.
I believe that in all other respects, your explanation of case 1 is
correct.
Case 2:
-------
>> The only element in the instance document which has the same namespace
>> as the schema namespace is fname. Thus, it is the only element which
>> will get schema-validated.
If you really understand what I said above, then you will see why this is
not quite correct. Which schema to use, and how much to validate is at
the discretion of the processor, possibly based on parameters or other
tailoring provided by the invoking application. So, it is quite possible
that your case 2 document is being consumed by an application that
specifically supplies the schema(s) to be used for the elements not
governed by a schemaLocation, (which in your example happens to consist of
elements which are not in any namespace), and/or chooses to honor or not
honor the schemaLocation attribute for urn:person-schema. Indeed, if the
application had some particular reason to do so, it could direct the
processor specifically to use some other schema components to validate
elements and attributes from urn:person-schema.
That said, it will be quite common for people to acquire and use
processors that will honor the schemaLocation attribute, and that will
signal errors or provide other indication when the designated schema is
inaccessible.
Case 3:
-------
The spirit of this example is correct, modulo the point repeated twice
above.
While we are on the subject, it is worth noting that we wrestled long and
hard with the scoping of schemaLocation attributes. The problem we have
is that the Namespaces Recommendation gives us the xmlns: mechanism, but
gives us know explicit means to provide modifiers on it. So, it is not
possible for us within an xmlns: attribute to actually designate the
schema. Worse (for our purposes), is that the following are absolutely
equivalent documents according to the Namespace's Recommendation:
<a:e xmlns:a="auri">
<a:f>
</a:f>
<a:f>
</a:f>
</a:e>
... and ...
<a:e xmlns:a="auri">
<aa:f xmlns:aa="auri">
</aa:f>
<a:f>
</a:f>
</a:e>
So the question arose for us, what would we do with constructions along
the lines of:
<a:e xmlns:a="auri" schemalocation="auri aschema1">
<aa:f xmlns:aa="auri" schemalocation="auri aschema2">
</aa:f>
<a:f schemalocation="auri aschema3">
</a:f>
</a:e>
all of which are syntactically correct according to the schemas working
draft? The answer we came up with is that there may be at most one
definition or declaration for any schema construction during the course of
a single validation. In principle, the schema processor can honor at most
one of the above schemaLocation attributes, presuming that the several
schemas include conflicting declarations for the same elements,
attributes, etc. In practice, constructions of this sort are strongly
discouraged.
There are several reasons for the restriction above, including: (1) it
would significantly complicate the implementation of processors to require
that the definitions be pushed and popped during the validation of a
single document, and (2) we wanted to admit implementations in which
various combinations of particular schemas were precompiled, particularly
for high-performance at the server. Such compilation is facilitated if
the definitions for elements, attributes, etc. are stable through the
validation. One way to combine such compilation with the use of the
schemaLocation attribute is to have the processor check that the
schemaLocation supplied in any instance agrees with the one used at the
time that schemas were precompiled, but such check is at the discretion of
the processor: as always the processor and application are free to
validate against what ever schema they choose to use.
I hope that you find these explanations to be helpful.
------------------------------------------------------------------------
Noah Mendelsohn Voice: 1-617-693-4036
Lotus Development Corp. Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------
"Roger L. Costello" <costello@mitre.org>
Sent by: www-xml-schema-comments-request@w3.org
01/04/00 09:22 AM
To: xml-dev@ic.ac.uk
cc: www-xml-schema-comments@w3c.org, "Schneider,John C." <jcs@mitre.org>,
"Cokus,Michael S." <msc@mitre.org>, "Costello,Roger L."
<costello@mitre.org>, (bcc: Noah Mendelsohn/CAM/Lotus)
Subject: Round 2: How an XML instance document references an XML Schema
Hi Folks,
There has been a considerable amount of discussion (and confusion) on
how an XML instance document indicates the XML Schema(s) that it
conforms to. I am not sure that it is yet clear in people's minds on
how to do it. I will take a stab at explaining it, based upon the
discussions. However, we really need this to be verified by someone
from the Schema WG.
[Henry, I haven't fully digested your most recent message. Hopefully
the following is consistent with what you said.]
[Also, thanks a lot to Henry Thompson, Andrew Layman, and Rick Jelliffe
for taking the time to answer my endless barrage of questions. I hope
that these questions and their answers are useful to all.]
Case 1. Entire instance document conforms to a single XML Schema
Let's use the example that Gabe Beged-Dov gave yesterday. Here's the
skeleton of the XML Schema:
<?xml version="1.0"?>
<!DOCTYPE schema SYSTEM "structures.dtd">
<schema xmlns="http://www.w3.org/1999/XMLSchema"
targetNamespace="urn:person-schema">
...
</schema>
Let's assume that the URI for this schema is:
urn:person-schema/person-schema.xsd
Thus the namespace for the elements and attributes that are declared in
person-schema.xsd is urn:person-schema.
An XML instance document that wishes to indicate that all or part of it
conforms to person-schema.xsd must use the attribute, schemaLocation.
The value of schemaLocation must include a pair of values - the
namespace (urn:person-schema) and the URI to the Schema
(urn:person-schema/person-schema.xsd). Thus, for this case the value of
schemaLocation is:
schemaLocation="urn:person-schema
urn:person-schema/person-schema.xsd"
A Schema-validating parser will use the URI to fetch the schema
document, and then will verify that the targetNamespace value matches
the namespace in schemaLocation.
The schemaLocation attribute is defined in the schema instance
namespace. So, to use it in our instance document we first need to
define a qualifier for the schema instance namespace and then prefix
schemaLocation:
xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance"
xsi:schemaLocation="urn:person-schema
urn:person-schema/person-schema.xsd"
Now then, is that all that's needed in the XML instance document -
simply add schemaLocation as an attribute to the root element, i.e.
<?xml version="1.0"?>
<Person xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance"
xsi:schemaLocation="urn:person-schema
urn:person-schema/person-schema.xsd">
<fname>Helen</fname>
<lname>Jones</lname>
</Person>
Based upon Andrew Layman's messages yesterday, the answer is no. I
believe that I now understand why. In the above instance document we
have not declared a namespace for the elements - Person, fname, and
lname. Thus, they are in the document's namespace. However, with the
schemaLocation attribute we are asserting that the elements declared in
the schema are in the urn:person-schema namespace. Thus, in our
instance document we must make a namespace declaration to indicate that
the elements in the instance document also are in the urn:person-schema
namespace. Since we want to declare that all the instance document
elements come from the urn:person-schema namespace, we can use it as the
default namespace. Thus, our instance document looks like this:
<?xml version="1.0"?>
<Person xmlns="urn:person-schema"
xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance"
xsi:schemaLocation="urn:person-schema
urn:person-schema/person-schema.xsd">
<fname>Helen</fname>
<lname>Jones</lname>
</Person>
Using the default namespace declaration, all the elements in the
instance document have the same namespace as the schema namespace.
Thus, the entire instance document will get schema-validated.
Case 2. Part of the instance document conforms to a single XML Schema
Let's use the same schema as above and the same instance document.
However, in this case let's suppose that we just want to validate
"fname" against the schema. What would the instance document look like?
As usual we use the schemaLocation attribute to indicate the schema that
we are using. In the instance document we need to distinguish between
those elements that are in the document namespace versus the fname
element which is in the urn:person-schema. We can do this anywhere, but
for simplicity let's do it at the root element:
<?xml version="1.0"?>
<Person xmlns:p="urn:person-schema"
xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance"
xsi:schemaLocation="urn:person-schema
urn:person-schema/person-schema.xsd">
<p:fname>Helen</p:fname>
<lname>Jones</lname>
</Person>
The only element in the instance document which has the same namespace
as the schema namespace is fname. Thus, it is the only element which
will get schema-validated.
Case 3. Instance document conforms to multiple XML Schemas
Let's suppose that we have a second schema. This second schema
specializes in defining last names (I know, it's silly):
<?xml version="1.0"?>
<!DOCTYPE schema SYSTEM "structures.dtd">
<schema xmlns="http://www.w3.org/1999/XMLSchema"
targetNamespace="urn:last-name-schema">
...
</schema>
Note that this second schema's namespace is:
urn:last-name-schema
Let's continue to use the same instance document. However, let's assume
that we want to validate fname against the first schema and lname
against the second schema. For the Person element, we don't want any
validation.
Our schemaLocation attribute now will have two pairs of values - the
first pair is for the first schema and the second pair is for the second
schema. We will declare the two different namespaces and prefix fname
and lname appropriately. Thus, the instance document is:
<?xml version="1.0"?>
<Person xmlns:p="urn:person-schema"
xmlns:l="urn:last-name-schema"
xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance"
xsi:schemaLocation="urn:person-schema
urn:person-schema/person-schema.xsd
urn:last-name-schema
urn:last-name-schema/last-name-schema.xsd">
<p:fname>Helen</p:fname>
<l:lname>Jones</l:lname>
</Person>
Well, I am getting tired of writing. Hopefully this makes sense. Even
more, hopefully it is correct. Comments? /Roger
Received on Tuesday, 4 January 2000 11:05:27 UTC