Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] XML Schema and instance documents

From: Jack Matheson <jack@----------.--->
To: xml-dev@-----.---.---
Date: 2/3/2006 10:52:00 PM
Excellent, that's what I was hoping for =)

Thanks again,
-Jack

> The spec gives implementations great latitude on this. I think that
> conforming processors could choose whichever definition they hit  
> first, or
> they could throw an error because there is more than one definition of
> {ns2}child, or they could recognize that the two definitions are  
> actually
> equivalent and avoid throwing the error. It's best to avoid the  
> situation
> arising.
>
> Saxon will tend to do the first of these: if you've already got a  
> schema (a
> set of schema components) for namespace {ns2} in your cache, then  
> an import
> of that namespace is a no-op, even if the schema location is  
> different. This
> is justified on the basis that the schema location is only a  
> "hint". As a
> general rule, it's troublesome to have several schemas in existence  
> for the
> same namespace - even though there are very good reasons for doing  
> it, such
> as validating the same document at different stages in its lifecycle.
>
> Michael Kay
> http://www.saxonica.com/
>
>> -----Original Message-----
>> From: Jack Matheson [mailto:jack@s...]
>> Sent: 03 February 2006 20:32
>> To: xml-dev@l...
>> Subject: [xml-dev] XML Schema and instance documents
>>
>> Can anyone tell me how a schema-aware validating parser
>> decides which
>> schema to use in this case:
>>
>> ns1.xsd:
>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>> targetNamespace="ns1">
>>     <xs:import schemaLocation="import.xsd" namespace="ns2"/>
>>
>>     <xs:element name="root"/>
>> </xs:schema>
>>
>> import.xsd:
>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>> targetNamespace="ns2">
>>     <xs:element name="child"/>
>> </xs:schema>
>>
>> ns2.xsd:
>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>> targetNamespace="ns2">
>>     <xs:element name="child"/>
>> </xs:schema>
>>
>> test.xml:
>> <a:root xmlns:a="ns1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
>> instance"
>>                xsi:schemaLocation="ns ns1.xsd ns2 ns2.xsd">
>>     <child xmlns="ns2"/>
>> </a:root>
>>
>> If I remove the "ns2 ns2.xsd" pairing from the instance document's
>> xsi:schemaLocation attribute, the rule defined by
>> import.xsd will be used. What happens when this attribute is
>> left in?
>> Is it up to the processor to decide?
>>
>> Any help is appreciated!
>>
>> -Jack
>>
>>
>> -----------------------------------------------------------------
>> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>> initiative of OASIS <http://www.oasis-open.org>
>>
>> The list archives are at http://lists.xml.org/archives/xml-dev/
>>
>> To subscribe or unsubscribe from this list use the subscription
>> manager: <http://www.oasis-open.org/mlmanage/index.php>
>>
>>
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent