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

Re: Multiple and circular import/include

From: Kasimier Buchcik <kbuchcik@4commerce.de>
Date: Thu, 10 Mar 2005 20:33:32 +0100
Message-ID: <4230A10C.9030702@4commerce.de>
To: noah_mendelsohn@us.ibm.com
CC: xmlschema-dev@w3.org

Hi,

[...]

>> 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.

One obvious example would be a scenario where an element "E"
is validated against a lax wildcard; at this point no declaration for
the element "E" exists, thus the element seems valid. A descendant
element imports an additional schema via xsi. This schema contains an
element declaration "DE" for "E", which -  if it would have been
available - would have identified the element "E" as invalid. So this
way the validation would differ from the schemata being computed all
at validation begin.

Every validator should have this problem; for non-streaming validators
there is still the chance to prescan the tree, or just hold a list of
suspicious nodes to come back again and revalidate.

But what should streaming validators do here? Preparsing the stream
is out of the question, since it would involve caching the whole stream,
to be able to read it again. Caching such suspicious elements, plus
their content, to check again when a declaration becomes available?
In the worst scenario that would mean caching nearly the whole stream
as well. How is managable in conjunction with resolving IDCs
selectors and fields?

I haven't thought yet about redefinitions in conjunction with
incremental assembling; so I would be glad to hear from someone if
I should prepare for problems here as well.

Did assembling via xsi broke streaming validation? Or does a relative
simple solution exist. Knowing that this issue is managable somehow in a
sane way would make it feel more comfortable :-)

>> 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.
[...]

Regards,

Kasimier
Received on Thursday, 10 March 2005 19:34:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:49 GMT