Re: [xsl] xinclude in XSLT[2]

Subject: Re: [xsl] xinclude in XSLT[2]
From: Frans Englich <frans.englich@xxxxxxxxx>
Date: Tue, 24 Oct 2006 17:10:06 +0200
On Tuesday 24 October 2006 08:02, Erik Wilde wrote:
> hello.

Hi Eric,

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

Do you know any location where this is described in detail? That is, exactly 
what parts are not possible to implement with XSL-T 2.0?


Cheers,

		Frans

Current Thread