Hi,

Henry S. Thompson wrote:
> Kasimier Buchcik <kbuchcik@4...> writes:
> 
> 
>>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.
> 
> 
> This is actually an error [1]:
> 
>   4. xsi:schemaLocation and xsi:noNamespaceSchemaLocation [attributes]
>      can occur on any element. However, it is an error if such an
>      attribute occurs after the first appearance of an element or
>      attribute information item within an element information item
>      initially *validated* whose [namespace name] it addresses.
> 
> This error is intended to 'protect' streaming validators from giving
> a different answer in this pathological case.
> 
> ht
> 
> [1] http://www.w3.org/TR/xmlschema-1/#schema-loc

Thank you very much! Now that you say it, it seems obvious; I see now
that I never got the meaning of this sentence right.

Just to be 100% sure here, is the following correct?

If an element or attribute is validated, all the components for its
namespace "N" must have been assembled already. If any following element
defines additional components for this namespace "N" to be assembled via
xsi, this results in an error. So the components for this namespace "N"
must be in a "final" state.

I can only guess that this restriction includes _indirect_ expansion of
components for this namespace "N", through schema documents with a
different targetNamespace, in which case I'd like to know if it would be
already an error to just mention the import of this targetNamespace "N",
or some of the components need to be identified as "new" to the
targetNamespace "N".

Thinking further, a streaming validation would only work if the state
of components with a specific targetNamespace is completely frozen at
the time of first usage for validation. This should include missing
sub-components as well; since, if component references could have been
resolved with the use of components assembled deeper in the tree, a
streaming validation would differ. So, once a component for a
specific targetNamespace was used for validation, don't change any
components with this targetNamespace.
Is this somehow anchored in the spec as well? Excuse me if I'm just
unable to find it the spec.

Regards,

Kasimier


From Ken_Gross@C... Mon Mar 14 16:56:38 2005
Received: from bart.w3.org ([128.30.52.40])
	by frink