While I haven't implemented an engine myself, I can imagine
it would be architecturally very disruptive since you are
conflating syntax with structure for this instruction. Right
now the <xsl:element> instruction and all of its attributes
construct result nodes in the result tree, while saying
nothing about serialization syntax. Adding your suggested
change would be introducing syntactic awareness to the
construction of the result tree for this instruction.
I acknowledge this is happening with the <xsl:text>
instruction and d-o-e, but I don't know of any other result
tree construction instruction that impacts on serialization.
Correct analysis. The architectural problem with d-o-e is that it requires
out-of-band communication between the XSLT processor and the serializer.
Instead of just passing a result tree and a set of serialization parameters
from the transformer to the serializer, there is a need to annotate
individual nodes of the tree with serialization properties (or in the case
of d-o-e, individual characters in a text node). This proposal has the same
problem.
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
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>
--~--