My ContentHandler is ready to handle that. More to the point, any
ContentHandler that expects to receive data from an XSL
transformation
had better be ready to handle that without falling over and dying,
because as we all know XSL transformations don't always generate
singly-rooted trees.
The problem is, I don't know whether the ContentHandler does expect to
receive data from an XSL transformation.
This problem first arose, as it happens, with FOP as the ContentHandler.
The way I handle this in Saxon 8.x is probably an improvement on my 6.x
design. There's now a serialization property you can set,
saxon:require-well-formed=yes|no, that tells Saxon whether the
ContentHandler can accept non-well-formed trees or not. The default is yes,
which suits some scenarios and not others.
Almost anything can
happen. A ContentHandler that does not control its parser should be
ready for this.
It's actually very difficult to write a ContentHandler that's ready for
anything, and I don't think many people attempt it. For example, most people
assume that namespaces will be notified using the default settings -
unfortunately a ContentHandler with no handle on the parser has no way of
finding out what these settings are. JAXP says nothing about how an XSLT
processor should notify namespace information to a SAXResult, so what is one
to do? There are also new problems in this area, for example is it
legitimate to send XML 1.1 names and namespace undeclarations to a
ContentHandler that hasn't indicated it is prepared to cope with them?
As you know yourself, the specs don't always provide the answers, and a
software designer has to make decisions. Describing a conscious decision
which happens to be different from the one you would have made as a "bug" is
not helpful.
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>
--~--