> 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/