[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: misprocessing namespaces (was Re: There is a

• To: "The Deviants" <xml-dev@l...>
• Subject: Re: misprocessing namespaces (was Re: There is a meaning, but it's not in the data alone)
• From: "Rick Jelliffe" <ricko@a...>
• Date: Mon, 4 Feb 2002 19:01:58 +1100
• References: <5.1.0.14.2.20020131082226.02822ec0@p...> <4XOKTPSQ3W1VLJ9607AZVUSBAUOYX05.3c586905@MChamp> <093701c1a9f2$71c37820$0a2e249b@n...> <3C589A61.95139DF@p...> <5.1.0.14.2.20020131082226.02822ec0@p...> <5.1.0.14.2.20020203204729.024ed7c0@p...>

From: "Tim Bray" <tbray@t...>
 
> I think xml:include is probably a better stab at a solution
> to the problem, but I also think we don't have enough experience
> to know how big/important the inclusion problem is, and what the
> right answer to it is.   -Tim
 
XInclude defines no processing order: it says it is an infoset-to-infoset transformation.

So anyone who wants to schema-validate XML documents before XInclusion
will need to make a version of their schema that sprinkles XInclude elements
at appropriate places as alternatives to content, and then, potentially, another
post-XInclusion infoset schema.  

However, since the top-level schemaLocation attributes are not re-written 
by the XInclude processing, AFAIK, it seems that the post-include infoset
is the more natural choice for doing validation: especially since how documents
are divided into entities or fragments is usually dependent on pragmatic
constraints that are not the kinds of things that one would make a schema
for.   

I wonder if XML Schemas should be revised to include some kind of
new "nill" element particle, which would allow partial validation of
documents with xincludes.  But then the problem of what it means 
in an ANY group would come up, and so on, so that seems unlikely.

So it seems to me that pre-inclusion infoset schema-validation is
really only useful for specific production purposes, while post-inclusion
infoset schema-validation is the processing model we should expect
for when using public schemas.


Cheers
Rick Jelliffe

• References:
  • Re: misprocessing namespaces (was Re: There is a meaning, but it's not in the data alone)
    • From: Tim Bray <tbray@t...>

• Prev by Date: Re: misprocessing namespaces (was Re: There is a meaning, but it's not in the data alone)
• Next by Date: Re: misprocessing namespaces (was Re: There is a meaning, but it's not in the data alone)
• Previous by thread: Re: misprocessing namespaces (was Re: There is a meaning, but it's not in the data alone)
• Next by thread: Re: misprocessing namespaces (was Re: There is a meaning, but it's not in the data alone)
• Index(es):
  • Date
  • Thread