Re: [xml-dev] Re: I can XInclude where I bloody want to

[Mike Brown <mike@skew.org>]

Paul Prescod wrote:
> 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?
  
For one, xsl:include can only occur in a certain place; it is essentially just          
for bringing children of the xsl:stylesheet element from one stylesheet into
another. It is not a general-purpose, application-side supplement to or
replacement of parsed general entity references at the parser level, as
XInclude is.

> 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 don't disagree, but I don't think it follows that XInclude processing
before XSLT processing violates the specs. It's just like the whitespace
preprocessing issue in MSXML's DOM.

XInclude doesn't conflict with the XML spec; it's something that goes on at 
the application side, at the application's discretion.

XInclude doesn't conflict with XSLT+XPath, either; XPath just says a virtual
tree, intended to be a certain kind of representation of an XML document,
exists and what it consists of. XSLT only covers the processing of that tree,
and an XSLT processor is only required to behave as if it is acting upon such
a tree. There are no rules as to how the tree is obtained. An XML document in
linear character form doesn't even have to be the source of the
representation; as has been pointed out before, the representation can come
into existence in any number of ways, and a parser doesn't even have to be
involved.

I think we take a lot of things for granted about the XSLT spec, based on the
implementations that have formed around it. An XSLT processor is only required
to behave as if it has acted upon a certain kind of abstract structure. It
really doesn't even require any input at all, as long as it always gives the
right result! Of course, since we don't have mind-reading software, we have to
give it some kind of input, and the implementations that have arisen do give
us convenient options for input -- but this input should be considered hints
to the processor to help it generate the result.

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

I don't see XInclude processing before XSLT processing as setting a terrible 
precedent. Having the option of turning it off will take care of the edge 
cases, and having it on by default isn't a violation of any specs or 
principles. If it violates assumptions that we tend to make because of how 
XML parsing and XSLT processing chains are traditionally set up, then perhaps 
there's an argument for a processor to be "nice" about it. 

I just keep thinking back to MSXML and whitespace, though. There's an example
of a processor bucking the trend, and on the whole, no one is really suffering
because of it. I think the reason for this is that most people pick an XSLT
processor, code to its quirks, its features and its APIs, and they stick with
it.

Your nightmare scenario is here today. It's a pie-in-the-sky idea to think
that XSLT processors are completely generic and interchangeable, and that XSLT
code can always be written to work identically on any XSLT processor. Anyone
who has dealt with processors having different ideas about relative URI
resolution, or anyone who has built an application on JAXP and then tried
switching processors from Saxon to Xalan* (or vice-versa, or in an environment
with multiple processors in the classpath), can probably attest to this. We're
just not there yet, and I don't think that it's a high priority.

   - Mike
____________________________________________________________________________
  mike j. brown                   |  xml/xslt: http://skew.org/xml/
  denver/boulder, colorado, usa   |  resume: http://skew.org/~mike/resume/


  * maybe this situation has improved since the last time I tried it