Re: Non-well-formed HTML in XSL

BTW In what configurations doesn't the solution work?

D-o-e can only work if the result tree is serialized
and reparsed. Support for d-o-e is actually part of
the XML serializer, not the transformation engine (which
just marks the nodes).

D-o-e wont work for most XML processing pipelines
as provided by Cocoon or the FOP CLI, because there
SAX events are used.

It is a pity that serialization is so tighly intermingled
with transformation in the minds of so many people, even
though the XSLT spec did reasonably good in separating
the issues.

It would be interesting to see the set of XML standards
a bit rearranged:
+ Data representation
 - logical data model (sort of infoset)
 - file format, including the canonical representations of
   syntactic elements and namespace syntax
 - in-memory data models (DOM, SAX)
 - more alternative XML representations as necessary
+ General purpose processing
 - parsing, parser processing model, parser configuration,
   parser APIs
 - serialization, processing model, serializer configuration,
   serializer APIs
 - aggregation / physical structure (xinclude), processing
   model, processor configuration and APIs
 - schema descriptions (DTD etc.)
 - validation, processing model, processor configuration and
   APIs
 - transformation, processing model, processor configuration
   and APIs
 - transparent embedding of encrypted, compressed, digitally
   signed or otherwise mangled XML data, processing model
   for expanding/decrypting/validating signatures etc.,
   processor configuration and APIs
+ standardized vocabularies for general use (FO, SVG,
  XHTML,...), preferably also with a processing model,
  processor configuration and APIs
The way currently various standards are arranged and
depend on each other appears to be grown (like cancer)
rather than designed.
Well, flammable topic...