Re: [xml-dev] [Summary] Big hierarchy of XML Schema documents ...which X

[Michael Kay <mike@saxonica.com>]

There are many issues being mixed here.

On interoperability, there are at least three reasons why you might get 
different results from different processors. One is because the 
specification leaves the behaviour of certain things 
implementation-defined (for example, whether a "dangling reference" to 
an unavailable component is an error, in the case where that component 
isn't actually used). A second reason is bugs - which should be fairly 
rare in reputable products. A third is deliberate non-conformances, 
which should be rare but aren't - sometimes vendors make the decision 
that they don't like part of the standard and they are going to do 
things differently. Unfortunately one of the most commonly used tools 
for XML schema development suffers particularly from this, and until 
users vote by taking their money elsewhere, the situation won't change. 
It's a case of buyer beware.

Generally, if part of a schema is invalid, then I would expect that 
invalidity to be reported whether or not that part of the schema is 
actually used in a particular validation episode.

 >But is there a way to avoid the additional processing time and memory 
use associated with loading in the extra schemas and validating them 
when you just want to validate XML instance documents?

You can only ask that question in the context of a particular product 
implementation. With Saxon, for example, I would advise you to save a 
.SCM file representing the compiled schema; reloading the schema from a 
.SCM file should be significantly faster than rebuilding it from source 
schema documents. Xerces, I believe, has options to load schema 
documents with partial validation which you can do if you are confident 
that the schema is valid.

Michael Kay
Saxonica

> Thanks,
> Nora
>
> -----Original Message-----
> From: Michael Kay [mailto:mike@saxonica.com]
> Sent: Thursday, August 05, 2010 6:15 PM
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] [Summary] Big hierarchy of XML Schema documents ... which XML Schema validators bring in the documents on demand?
>
> I'm not sure I really understand the question. That's partly because
> your terminology isn't precise. The processor constructs a schema by
> loading schema documents. The schema is a set of schema components
> derived from the schema documents. There are constraints that schema
> documents must satisfy, and there are constraints that schema components
> must satisfy, and there are constraints on the schema as a whole (e.g.
> no two element declarations with the same name). Loosely, you can talk
> about a schema document being valid if it satisfies the constraints on
> schema documents, and you can talk about schemas being valid if all the
> components satisfy the constraints on components (though some people
> prefer not to entertain the notion that the set of all schemas includes
> some that are valid and some that are invalid).
>
> I don't understand your idea that a "schema" might be considered valid
> by one validator and not by another. Perhaps I don't even understand
> what you mean by a "validator". It's true of course that a schema can be
> invalid because of inconsistency between its parts (for example, two
> element declarations with the same name and different definitions) where
> each of the components is valid when considered alone. Is that what you
> had in mind?
>
> Michael Kay
> Saxonica
>
>
>
> On 05/08/2010 17:21, Dowling, Nora M. wrote:
>    
>> Hi, all,
>>
>> During the validation of an XML document, is there a difference between the validator "loading a schema" and "validating the schema as it is loaded"?
>>
>> Of particular concern is the case where the linked-in schema is considered valid by another validator but not by the one currently validating the XML document (the schema for which includes a schema that includes the schema that the current validator thinks is invalid).  How do the various validators handle this when:
>>
>> 1) the XML document being validated never makes use of the schema;
>> 2) it makes use only of the valid parts of the linked-in schema; and
>> 3) it uses the "invalid" definition in the schema?
>>
>> Thanks,
>>
>> Nora Dowling
>> The MITRE Corporation
>>
>> -----Original Message-----
>> From: Costello, Roger L. [mailto:costello@mitre.org]
>> Sent: Thursday, August 05, 2010 7:55 AM
>> To: xml-dev@lists.xml.org
>> Subject: RE: [xml-dev] [Summary] Big hierarchy of XML Schema documents ... which XML Schema validators bring in the documents on demand?
>>
>> Good. Thanks Michael. I've got it.
>>
>> Do the other schema validators behave in the same way?
>>
>> Michael Kay: does SAXON behave the same way?
>>
>>
>> /Roger
>>
>>
>> From: Michael Glavassevich [mailto:mrglavas@ca.ibm.com]
>> Sent: Wednesday, August 04, 2010 5:06 PM
>> To: Costello, Roger L.
>> Cc: xml-dev@lists.xml.org
>> Subject: RE: [xml-dev] [Summary] Big hierarchy of XML Schema documents ... which XML Schema validators bring in the documents on demand?
>>
>> It depends on what you put in Library.xsd. If you import Book.xsd then it will get loaded with it:
>>
>> <xs:import namespace="http://www.book.org"; schemaLocation="Book.xsd"/>
>> <xs:complexType name="BooksType">
>>    <xs:sequence>
>>     <xs:element xmlns:x="http://www.book.org"; ref="x:Book"/>
>>    </xs:sequence>
>> </xs:complexType>
>>
>> If the schema documents aren't directly connected:
>>
>> <xs:complexType name="BooksType">
>>    <xs:sequence>
>>     <xs:any namespace="http://www.book.org"/>
>>    </xs:sequence>
>> </xs:complexType>
>>
>> then Book.xsd won't be loaded until Xerces-J's validator hits<Book>.
>>
>> Thanks.
>>
>> Michael Glavassevich
>> XML Parser Development
>> IBM Toronto Lab
>> E-mail: mrglavas@ca.ibm.com
>> E-mail: mrglavas@apache.org
>>
>> "Costello, Roger L."<costello@mitre.org>   wrote on 08/04/2010 04:33:41 PM:
>>
>>
>>      
>>> Hi Michael,
>>>
>>> Sorry for my misunderstanding. Let me be sure that I now understand
>>> correctly.
>>>
>>> Consider this XML document:
>>>
>>> <?xml version="1.0"?>
>>> <Library xmlns="http://www.library.org";
>>>            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>>            xsi:schemaLocation=
>>>                       "http://www.library.org
>>>                        Library.xsd">
>>>       <Books>
>>>           <Book xmlns=http://www.book.org
>>>                 xsi:schemaLocation=
>>>                              "http://www.book.org
>>>                               Book.xsd">
>>>                   <Title>My Life and Times</Title>
>>>                   <Author>Paul McCartney</Author>
>>>                   <Date>1998</Date>
>>>                   <ISBN>1-56592-235-2</ISBN>
>>>                   <Publisher>Macmillan Publishing</Publisher>
>>>           </Book>
>>>           ...
>>>       </Books>
>>> </Library>
>>>
>>> Xerces-J will not read Book.xsd until it gets to the<Book>   element.
>>> It will read Library.xsd immediately. Is that correct?
>>>
>>> /Roger
>>>
>>>
>>> From: Michael Glavassevich [mailto:mrglavas@ca.ibm.com]
>>> Sent: Wednesday, August 04, 2010 3:43 PM
>>> To: xml-dev@lists.xml.org
>>> Subject: Re: [xml-dev] [Summary] Big hierarchy of XML Schema
>>> documents ... which XML Schema validators bring in the documents on demand?
>>>
>>> Roger,
>>>
>>> "Costello, Roger L."<costello@mitre.org>   wrote on 07/31/2010 01:50:37 PM:
>>>
>>>
>>>        
>>>> Hi Folks,
>>>>
>>>> Thanks to Michael Glavassevich, Michael Kay, and Boris Kolpackov for
>>>> your excellent inputs.
>>>>
>>>> Here's what I learned (please correct any errors):
>>>>
>>>> Suppose that your XML Schema imports/includes some XML Schemas, and
>>>> they import/include some XML Schemas, and so on. Thus, there is a
>>>> big hierarchy of XML Schema documents.
>>>>
>>>> When does a validator read the XML Schema documents? Here are two
>>>> ways that XML Schema validators could be implemented:
>>>>
>>>> 1. Just-in-time loading (a.k.a. on-demand loading): the validator
>>>> reads an XML Schema document during instance validation, when a
>>>> component from the relevant namespace is first encountered.
>>>>
>>>> 2. Eager loading: all XML Schema documents are (recursively) read
>>>> prior to validating the XML instance document.
>>>>
>>>>          
>>> This is quite a different statement than what you originally had and
>>> is no longer an accurate description of how / when Xerces-J
>>> dynamically loads schemas. There could be multiple schema location
>>> hints (i.e. xsi:schemaLocation) in a document and Xerces-J won't
>>> load those schema documents unless the validator hits an element,
>>> attribute or type which has the target namespace of those schemas.
>>> If they don't import each other loading one of them won't cause the
>>> others to be loaded. The others might be loaded later if they're needed.
>>>
>>>
>>>        
>>>> The following XML Schema validators all use eager loading:
>>>>
>>>>       SAXON (Java)
>>>>
>>>>       SAXON (.NET)
>>>>
>>>>       XERCES (Java)
>>>>
>>>>       XERCES (C++)
>>>>
>>>>       XERCES (Perl)
>>>>
>>>>       LIBXML (Gnome's libxml2)
>>>>
>>>>       MSXML
>>>>
>>>>       XSV
>>>>
>>>>
>>>> /Roger
>>>>
>>>> _______________________________________________________________________
>>>>
>>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>>>> to support XML implementation and development. To minimize
>>>> spam in the archives, you must subscribe before posting.
>>>>
>>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>>>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>>>> subscribe: xml-dev-subscribe@lists.xml.org
>>>> List archive: http://lists.xml.org/archives/xml-dev/
>>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>>>
>>>>          
>>> Thanks.
>>>
>>> Michael Glavassevich
>>> XML Parser Development
>>> IBM Toronto Lab
>>> E-mail: mrglavas@ca.ibm.com
>>> E-mail: mrglavas@apache.org
>>>
>>> _______________________________________________________________________
>>>
>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>>> to support XML implementation and development. To minimize
>>> spam in the archives, you must subscribe before posting.
>>>
>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>>> subscribe: xml-dev-subscribe@lists.xml.org
>>> List archive: http://lists.xml.org/archives/xml-dev/
>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>>
>>>        
>> _______________________________________________________________________
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> to support XML implementation and development. To minimize
>> spam in the archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>>
>> _______________________________________________________________________
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> to support XML implementation and development. To minimize
>> spam in the archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>>
>>
>>      
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>
>