Lists Home |
Date Index |
- To: "The Deviants" <firstname.lastname@example.org>
- Subject: Re: [xml-dev] misprocessing namespaces (was Re: [xml-dev] There is a meaning, but it's not in the data alone)
- From: "Rick Jelliffe" <email@example.com>
- Date: Mon, 4 Feb 2002 19:01:58 +1100
- References: <firstname.lastname@example.org> <4XOKTPSQ3W1VLJ9607AZVUSBAUOYX05.3c586905@MChamp> <email@example.com> <3C589A61.95139DF@prescod.net> <firstname.lastname@example.org> <email@example.com>
From: "Tim Bray" <firstname.lastname@example.org>
> 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
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.