Re: [xsl] xinclude in XSLT[2]

Subject: Re: [xsl] xinclude in XSLT[2]
From: Frans Englich <frans.englich@xxxxxxxxx>
Date: Wed, 25 Oct 2006 13:18:27 +0200
On Tuesday 24 October 2006 18:07, Erik Wilde wrote:
> hello frans.
> > 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?
> i don't think that there is a good description anywhere. i asked this
> question on xsl-list in august, but only received rather vague replies
> (
> so i had to go through xinclude and xslt, and there are two things that
> xinclude requires you to do, and that xslt does not let you do:
> -
> -
> the writing of these sections is not very clear, because it does not
> explicitly say that this MUST be done, but as i understand the text,
> this is what it means.
> both of these things are not available in xslt, because the xpath node
> tree (or the xdm, depending on which version of xslt you are looking at)
> does not include this information.
> (in xdm, unparsed entities in the infoset may be included in the data
> model, but they are optional.)

I presume the accept-language and accept attribute/HTTP headers can't be 
implemented either. Is there some other optional feature beyond any XPointer 
scheme except element() that can't be implemented?

(I guess the support for XPointer schemes is determined by what the XSL-T 
implementation supports, if the URI is passed to document() unchanged).

> so, because there is this discrepancy between xinclude and xslt, i think
> there should be at least an appendix in xinclude talking about this,
> because the idea of implementing xinclude with xslt is not that
> far-fetched. so if you also think that at least xinclude should be more
> explicit about no being xslt-friendly, then look at the latest draft
> and send a comment to
> about
> including such an appendix in the next version of the specification.
> personally, i think it would be much better to change the spec so that
> it is xslt-friendly (i.e., is defined in a way so that it can be
> implemented in xslt), but this may be too much to ask for for a minot
> version revision...

This is how I feel about it:

An informational paragraph on implementing XInclude with XSL-T is a too 
hefty change for the spec's status, in my opinion. However, one could add 
something similar to W3C's public page on XInclude(points to threads like 
this, etc).

Changing the requirements for the spec is of course an invasive change. I 
think it is the general problem of mixed data models in the XML world and 
that many loath the complexity of DTDs/unparsed entities. If XInclude was 
written today, it would perhaps had been abstracted from specifying a 
specific data model(by using its own data model, heh?) or only support a
common subset of wide spread data models.

One way to look at this is "XInclude can't be used with XQuery & XSL-T" but it 
is afterall the XPath Data Model that imposes the "restriction", not the 
other way around.

I guess this means that the alleged problems of 
implementing XInclude with XSL-T can't occur in practice(since the ignored 
infoset parts wouldn't be represented no matter what), so it is "only" a 
matter of paper work -- to be able to claim strict conformance. Though, I do 
agree that is important.

One thing that I think would ease implementing XInclude with XSL-T is an error 
namespace that optionally can be used. In this way the implementation can use 
fn:error() to clearly signal XInclude errors. Perhaps I should send off a 
note on that.



Current Thread