Re: duplicate schemalocation keys

Hi Xan,

> We recently saw an instance document that supplied multiple schema
> location values for the same namespace.
>
> The document starts:
>
> <p1:envelope
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
>   xmlns:p1="http://www.example.org/schemas/ns1" 
>   xsi:schemaLocation="
> http://www.example.org/schemas/ns1 Envelope.xsd 
> http://www.example.org/schemas/ns1 Transaction.xsd 
> http://www.example.org/schemas/ns1 Document.xsd 
> http://www.example.org/schemas/ns1 Event.xsd">
>
> I know the REC doesn't say what to do, but is there a common
> practice of how to handle such locations? Use first that exists?
> Combine all that exist? Ignore all but first? Give warning?

Most processors will only load the first that they can find, I think.
The rules are at http://www.w3.org/TR/xmlschema-1/#schema_reference,
which says:

  Given a namespace name (or none) and (optionally) a URI reference
  from xsi:schemaLocation or xsi:noNamespaceSchemaLocation,
  schema-aware processors may implement any combination of the
  following strategies, in any order:

  1 Do nothing, for instance because a schema containing components
    for the given namespace name is already known to be available, or
    because it is known in advance that no efforts to locate schema
    documents will be successful (for example in embedded systems);

  2 Based on the location URI, identify an existing schema document,
    either as a resource which is an XML document or a <schema>
    element information item, in some local schema repository;

  3 Based on the namespace name, identify an existing schema
    document, either as a resource which is an XML document or a
    <schema> element information item, in some local schema
    repository;

  4 Attempt to resolve the location URI, to locate a resource on the
    web which is or contains or references a <schema> element;

  5 Attempt to resolve the namespace name to locate such a resource.

  Whenever possible configuration and/or invocation options for
  selecting and/or ordering the implemented strategies should be
  provided.

Elsewhere, the Rec encourages processors not to import schemas that it
already has. So I think that you should only provide multiple schema
locations if they are *alternative* schema locations.

Cheers,

Jeni

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

Received on Saturday, 27 April 2002 05:31:28 UTC