Uche Ogbuji wrote:
>
>...
>
> > Uche, does your document() function also do XInclude expansion?
>
> If the user choses it to, then yes.
>
> As I pointed out, to XInclude or not to XInclude is optional for
> the user in 4XSLT.
Okay, but as an *extra action* not specified by either XSLT or XML
specifications, I'd say it should default to off for input documents.
I'm wouldn't mind it defaulting to ON for XSLT stylesheets. On the other
hand, what value does XInclude provide above and beyond xsl:include?
>...
> Also, this smells like a red herring to me. The result of
> calling document() can also be different based on whether or
> not a validating parser is used, or based on the exact format of
> the HTTP request that is made, in the case of an HTTP URL. This
> is the ambiguity we deal with in the XML world, and all
> technologies suffer such ambiguities.
I agree, but I see them as *problems* because they reduce
predictability. I don't think that one should voluntarily increase the
number of ambiguities that we need to deal with. BTW, the distinction of
validating parsers versus "regular" parsers is a clear violation of one
of the principles that was supposed to guide XML's development: "no
optional features."
>...
> Do you mean an extension element of some sort to set the option?
> Chicken and egg problem. It has to read the XSLT in order to
> see the extension, and it would need to apply XInclude, if desired,
> while reading the XSLT. A 2 pass solution is probably out of the
> question because of performance.
You could merely require the declaration to precede the first XInclude.
But again I don't really no the value of XInclude *for XSLT stylesheets*
(whereas I can see more value for the input document).
Daniel Villard said:
> BTW, my recollection of last year W3C Workshop on XML processing model
> there was one thing *cristal* clear:
>
> "There is no single processing chain which fits everybody's need"
That's why I would say that you should default to doing only things
explicitly described in the XSLT and XML specifications and let people
layer on their own ordering of behaviours. First do no harm!
I believe that it is relatively easy in XSLT 2.0 to "manually" apply
XInclude as a pre-process. And you could make the XInclusion automatic
through an XSLT extension declaration. One way to do it would be:
<xsl:template select="/">
<xsl:apply-templates select="xinclude:include(.)"/>
</xsl:template>
Another way would be a top-level statement
<xinclude:declare inclusion="automatic"/>
I think that it will become *very* confusing if every XSLT processor
starts choosing its own set of preprocessing steps to apply silently.
You'll do XInclude. Someone else will apply the SOAP inclusions. Someone
else will do some kind of annoation based on their favorite schema
language. Eventually to use an XSLT processor you have to go through a
long mental checklist about what features will be applied and *how to
turn them off*.
Paul Prescod
