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. http://www.w3.org/TR/xinclude/#infoset 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).