W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2005

Re: Multiple and circular import/include

From: Kasimier Buchcik <kbuchcik@4commerce.de>
Date: Mon, 07 Mar 2005 16:31:44 +0100
Message-ID: <422C73E0.3090100@4commerce.de>
To: noah_mendelsohn@us.ibm.com
CC: xmlschema-dev@w3.org


tiny need of clarification regarding incremental imports via

noah_mendelsohn@us.ibm.com wrote:
> FWIW, Schema 1.1 will attempt to clarify details of inclusion, import, 
> etc.    Though the Workgroup has not yet agreed on specific language, my 
> expectation is that it will be made very clear that cycles in the graph of 
> inclusion, import, xsi:schemaLocation, etc.  are definitely allowed.  As 
> someone has noted they are useful.  Circular redefines typically make no 
> sense, and I expect that they will be disallowed.
> While implementations are free to get the right answer anyway they can, I 
> expect that the design will be compatible with an algorithm along the 
> following lines:
> 1. Compute the set of files resulting from the transitive closure of a) 
> all the schema docs explicitly named on a command line, API, or similar 
> processor-dependent mechanism b) files included by them c) imports for 
> which schemaLocation is honored d) xsi:schemaLocations that are honored d) 
> redefines.   Note that transitive closures don't look infinitely on 
> cycles.   We just collect a set of filenames.
> 2.  Check for cycles in the redefine graph.
> 3.  Compute the schema resulting from this collection of schema docuemnts
> The above oversimplifies many details, including among others "chamelon 
> include"  (include of a document with no targetNamespace by a doc that has 
> one), but the spirit is right.
> If you're wondering about incremental processing of xsi:schemaLocations as 
> the validation proceeds, that's allowed, but it's only an optimization. 
> The results must be the same as if you had prescanned the instance to find 
> the schemaLocations you intended to honor, included the files for them in 
> advance in step 1, and computed the schema in bulk.  It turns out that 

Wouldn't this break streaming validation? If streaming, such a
schema to be imported is not known until that specific importing node is
reached - the preceeding nodes of the tree do not know of it. Are
streaming validators expected to prescan the instance, resulting in
parsing an instance document _twice_? Sounds strange to me, but maby
I didn't get the statement right.

> certain rules in the schema language make it practical to do such 
> incremental construction, but they are not fundamental to the language any 
> more than JIT'ing, for example is part of the Java language definition. 
> It's a cool incremental optimiation, but the burden is on you to get the 
> same result as if you had run the same program without incremental 
> compilation.
> Again, these are all just my intuitions as to how the clarifications will 
> come out.  At least some of us in the WG believe that this is how schema 
> 1.0 works, but all agree that the recommendation is at best vague and most 
> likely contradictory in these areas.




Received on Monday, 7 March 2005 15:32:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:07 UTC