Re: [xsl] xinclude in xslt2

Subject: Re: [xsl] xinclude in xslt2
From: Erik Wilde <net.dret@xxxxxxxx>
Date: Sat, 19 Aug 2006 11:18:09 -0700

Erik Wilde wrote:
From: Colin Paul Adams <colin@xxxxxxxxxxxxxxxxxx>
"Erik" == Erik Wilde <net.dret@xxxxxxxx> writes:
    Erik> apart from that, i cannot imagine what the hard parts should
    Erik> be, but maybe i am a bit to naive. anyway, i would be very
    Erik> happy to be pointed to a list of potential problems before i
    Erik> get started.
I seem to recall that there are parts of the infoset that XInclude
needs that an XSLT processor never gets to see, as they aren't in the
XPath Data Model. But my memory is rather vague on this.
if anybody could mention if this really is the case, i would be most grateful. to me looks as if the "must" parts are all satisfied by the infoset view of xslt, whereas the "may" parts ("include history" and "language" properties) definitely are a problem. but they are optional.

i probably should have looked into other parts of the xinclude spec as well (the #infoset part does not really list everything that is needed). in the sections about unparsed entities and notations, it is said that these items must be merged (while discarding duplicates). this is not good, because these items are not visible in xslt. this is probably what you were referring to. so looks as if you were right. however:

there used to be a feature in xslt 2.0 which could have saved us, at least as an optional feature (does/did saxon support this? or any other xslt 2.0 proecssor?):

unfortunately, this useful section has been removed from the spec. does anybody know the reason? i do think that xslt's somewhat reduced view of an infoset in principle is a good thing, but it would have been nice to have the opportunity to get to the other parts as well, at least as an optional feature. xinclude is a good example for that.

so this means that xslt 2.0 is probably good for implementing an xinclude processor as mentioned in the #infoset section of the xinclude spec, but unfortunately this section is not complete. it is my understanding that a conforming xinclude processor must also process unparsed entity declarations and notation declarations, which are a problem. with xslt 2.0 "lex:" namespace, this would have been possible, without this, i think there is no easy way how to handle it.

since i (and probably 99.9999% of all xml users) do not use unparsed entities and notations, i would be happy to have an xinclude processor not supporting them, but it looks as if an xinclude processor is not allowed to ignore them. there are no *must* clauses in the sections about unparsed entities and notations, however, but i guess this is more sloppy wording than meaning that they are not mandatory.

so, from all of this i include that i will probably produce a non-conforming xinclude processor in xslt 2.0, which could be extended to a conforming xinclude processor rather easily if the "lex:" namespace were supported by the underlying xslt processor. if not, this is not a problem for me and the majority of other potential users of xinclude. it would be nice if xinclude would somehow reflect the xslt-view of xml (maybe as a possible conformance level).

thanks for any additional commant and kind regards,

erik wilde     tel:+1-510-6421464 - fax:+1-510-6425814
     dret@xxxxxxxxxxxxxxxxx -
     School of Information - UC Berkeley (ISchool/UCB)

Current Thread