This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Non-well-formed HTML in XSL
- From: "J.Pietschmann" <j3322ptm at yahoo dot de>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Thu, 18 Jul 2002 22:29:20 +0200
- Subject: Re: [xsl] Non-well-formed HTML in XSL
- References: <03F3A585B9FE034EB571F04E4C792E220545C09A@2k_exch.analysys.com>
- Reply-to: xsl-list at lists dot mulberrytech dot com
Richard Mitchell wrote:
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...
J.Pietschmann
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list