Hi,

tiny need of clarification regarding incremental imports via
xsi:schemaLocation...

noah_mendelsohn@u... 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.

[...]

Regards,

Kasimier
Regards,

Kasimier

From a.zerdazi@i... Tue Mar 08 13:21:15 2005
Received: from wiggum.w3.org ([128.30.52.23])
	by f