hello.
It looks pretty much feasible now in XSLT 2.0. The only probable
problems are related to the fact that XInclude is designed to operate at
very low XML processing level. For starters:
1. detecting circular inclusions
2. xml:base fixup
3. xml:lang fixup
4. dealing with fatal and resource errors, e.g. the case when included
document is unavailable and is non-well-formed should be distinguished.
detecting circular inclusions is easy, and the xml:base and xml:lang
attributes should be easy to handle, as they are easily accessible
through the xpath node tree.
wrt handling the different types of errors: you are probably right here,
using xpath's and xslt's functions for accessing documents, it is not
possible to distinguish the two types of errors. for example, the
document() function of xslt will simply return an empty node set in case
of an error. xpath's doc() could do better, if supported by the
implementation:
from http://www.w3.org/TR/xpath-functions/#func-doc: "Implementations
may provide user-defined error handling options that allow processing to
continue following an error in retrieving a resource, or in parsing and
validating its content. When errors have been handled in this way, the
function may return either an empty sequence, or a fallback document
provided by the error handler."
http://www.saxonica.com/documentation/functions/intro/fn_doc.html
however does not mention anything about saxon supporting user-defined
error handling for doc().
and then we have this problem of unparsed entities and notations, which
are not accessible to the xslt processor at all (unless it provided one
way to access them in addition to the standard xpath node tree).
thanks for your comments and kind regards,
dret.
--~------------------------------------------------------------------
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>
--~--