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