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
(http://www.biglist.com/lists/xsl-list/archives/200608/msg00450.html).
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:
- http://www.w3.org/TR/xinclude/#notations
- http://www.w3.org/TR/xinclude/#unparsed-entities
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.
http://www.w3.org/TR/xpath#infoset
http://www.w3.org/TR/xpath-datamodel/#infoset-conformance
(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
http://www.w3.org/TR/2006/PER-xinclude-20061003/ and send a comment to
http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/ 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.
Cheers,
Frans
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--