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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] xinclude in XSLT[2], Erik Wilde | Thread | Re: [xsl] xinclude in XSLT[2], Erik Wilde |
Re: [xsl] getting type information , Dimitre Novatchev | Date | [xsl] Combining two template matche, Aaron Johnson |
Month |