XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Big hierarchy of XML Schema documents ... which XMLSchema validators bring in the documents on demand?

On 28/07/2010 21:05, Costello, Roger L. wrote:
> Hi Folks,
>
> Suppose that my XML Schema imports/includes some XML Schemas and they import/include some XML Schemas and so on. That is, there is a big hierarchy of XML Schema documents.
>
> I envision two ways that XML Schema validators could be implemented:
>
> 1. On-demand: the validator brings in an XML Schema document only when it's needed. (On-demand/Just-in-time/Dynamic-Loading)
>
> 2. Not on-demand: when the validator brings in an XML Schema document it also brings in the XML Schema documents it imports/includes and the documents they import/include and so on. (What is the right term for this?)
>
> I am interested to know how these XML Schema validators operate with regard to being on-demand or not. Can you help to fill in this table please:
>
>    

By "on-demand" do you mean only during instance validation, when a 
component from the relevant namespace is first encountered? I think 
that's rather hard to achieve in practice. The schema processor 
typically converts the grammar for the content model of a complex type 
into a finite state machine, and you can't do that without knowing all 
the members of a substitution group, which you don't know until you've 
read all the schema documents. Also, it would mean that some errors in 
schemas (notably UPA violations) would not be found until you first used 
the schema with an instance document that triggered the appropriate checks.

Some degree of incremental schema construction is implied by the spec, 
in the case where an instance document contains multiple 
xsi:schemaLocation attributes (e.g. an xsi:schemaLocation for the SVG 
namespace might be found on an svg:svg element deep within the 
document). But processors have some discretion here in what they allow; 
Saxon wouldn't allow such a late-arriving schema document, for example, 
to add new members to a substitution group that has already been used 
for validating previous elements.

So for Saxon, as far as schema documents referenced using xs:import and 
xs:include are concerned, the answer is that they are processed eagerly. 
(The internal sequence of operations, whether schema documents are 
turned into schema components before all the imports/includes are 
processed, is another matter entirely and largely of no concern to the 
user.)

Michael Kay
Saxonica


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS