Re: [xsl] xinclude in XSLT[2]

[Erik Wilde <net.dret@xxxxxxxx>]

hello.

i am glad that others are interested in xinclude implementations in xslt 
as well. unfortunately, after looking at it in more detail, i am now 
convinced that - given the current specifications - xinclude cannot be 
implemented in xslt, because some of the information required to be 
processed simply is not available in xslt. too bad, but there is nothing 
we can do about it.

i find it unfortunate to see w3c specifications being aligned this 
poorly, so that on the one hand, xslt is promoted as a technology to 
transform xml, while on the other hand, when looking at the (extremely 
useful) xinclude functionality, it is impossible to implement this using 
an xslt pipeline.

i sent an email about this to the authors of the second edition of 
xinclude (http://www.w3.org/TR/2006/PER-xinclude-20061003/), which is 
currently in the w3c process. i proposed the following actions for this 
second edition:

"- it might be helpful to add a section about why xinclude cannot be 
implemented with xslt (2.0). this could clarify this issue to people 
looking for how to use generic inclusion facilities in xslt. currently, 
xslt is not mentioned in the xinclude recommendation at all.

- it would be even better to turn the non-xslt-accessible parts of 
required xinclude behavior into optional behavior, so that it would 
become possible to implement xinclude using xslt 2.0. this way, such an 
xslt-based xinclude processor could call itself 'minimally conformant', 
while other implementations could claim to support a higher levels of 
conformance. "

the answer was basically that xinclude operates on a different level 
than xslt, and therefore no such changes should be made to the 
specification. i do now that there are differences in the underlying 
data models (after all, this is where the problems come from), but i 
still think that it would be good to align standards better, so that 
these legacy things of xml (notations and unparsed entities) do not make 
it impossible to create an conforming implementation of a useful 
specification. i will go ahead and implement an xinclude version in 
xslt, and it will be non-conformant, but i think it would be better if 
there would be a way to somehow say how an "xslt-possible" xinclude 
should look like.

to me, this simply is a question of what xml users should be given as a 
toolset, and i think that xslt-based xml users should be given tools to 
include contents from other resources.

practically, this means i have to downgrade my xipr implementation goals 
to what is feasible given the limitations of the toolset the w3c is 
giving us. this means that an xslt-based xinclude processor by 
definition will be non-conforming, but practically speaking, you don't 
need to care about this, because this will only affect information that 
is not accessible in xslt anyway...

cheers,

dret.