Re: [xsl] xinclude in XSLT[2]

Subject: Re: [xsl] xinclude in XSLT[2]
From: Erik Wilde <net.dret@xxxxxxxx>
Date: Mon, 23 Oct 2006 23:02:30 -0700
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.

Current Thread