Re: [xml-dev] using schemaLocation to point multiple same namespace schemas

[Jeni Tennison <jeni@jenitennison.com>]

Hi Manos,

> Thanks for your reply. The spec seams a little contradictive to me,
> since it urges me to use
>
> <p1:root xmlns:p1="NS_URI1"
>   xsi:schemaLocation="NS_URI1 schemaLocation1"
>
> to bind a schema (location) to a namespace URI, while allowing
> processors to ignore the second URI and try to resolve the schema
> using the first one... this does not "degrade well"...

I'm fully prepared to agree that the "specification" about how to
locate a schema for a particular document is very loose in the W3C XML
Schema Recommendation. I'm under the impression that this was
intentional, because different applications might want to use
different mechanisms for retrieving schemas -- an authoring
environment might want to use the xsi:schemaLocation attribute; a
DOM-based application might want to hard code the schemas that are
used to validate the documents it accepts; an application in a closed
environment might want to use a catalog of some kind to locate
schemas based on the namespace URI; and so on.

But I don't understand what problem you're encountering with the
example you gave above. In the above, you're saying that the schema
for the namespace NS_URI1 is located at the schema location
schemaLocation1. Those processors that use the xsi:schemaLocation
attribute should have no problems with this -- they should use the
schemaLocation1 as the location of the schema for the NS_URI1
namespace.

>> This option implies that if you already have a schema for a given
>> namespace then there is no need to find another one.
>
> True but different practices collide (see above).
>
> What about the case of:
>
> <p1:root xmlns:p1="URI1" xmlns:p2="URI2"
> xsi:schemaLocation="URI1 schemaLocation1 URI2 schemaLocation2"

Here, you're saying that the schema for the namespace URI1 is at
schemaLocation1 and the schema for the namespace URI2 is at
schemaLocation2.

Again, I don't think that there's any problem here. Schema validators
that use the xsi:schemaLocation attribute will locate the schemas at
schemaLocation1 (to validate nodes in the URI1 namespace) and at
schemaLocation2 (to validate nodes in the URI2 namespace), and combine
them to create the schema against which the document will be
validated.

The issue I thought we were discussing was when you have:

<p1:root xmlns:p1="URI1"
         xsi:schemaLocation="URI1 schemaLocation1
                             URI1 schemaLocation2" />

Here, I'm saying that the schema for the namespace URI1 is at
schemaLocation1. I'm also saying that the schema for the namespace
URI1 is at schemaLocation2. There are two locations for the schema for
the namespace URI1.

As I said, in these situations, a processor is within its rights,
according to the spec, to ignore schemaLocation2 and only use the
schema from schemaLocation1. By the time it comes across the
definition that says that the schema for the namespace URI1 is at
schemaLocation2, it already has a schema for that namespace -- the one
it found at schemaLocation1. (If it didn't manage to retrieve a schema
from schemaLocation1, I think it should try to retrieve one from
schemaLocation2, such that if you do specify multiple schema locations
for a particular namespace URI then they should be alternative
locations.)

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/