RE: Fixing <b>

>The
>standard response really is to either goad the people responsible for the
>crappy data into fixing it, or to not use XSLT, because trying to work with
>this kind of data in XSLT, in the way that you want to do it, while not
>impossible, requires using a much despised feature
(disable-output-escaping)
>that undermines the language's principle of being something meant to work
with
>trees, rather than being a general text processing tool.

Actually, I think the basic problem, of processing unparsed XML data that
arrives as a string, is quite a common one and can arise for some legitimate
reasons. Using disable-output-escaping isn't a nice way of dealing with it,
but I think one could clean up the semantics to make it workable. I'm
thinking in terms of a facility that says "Here is some XML, represented as
unparsed text containing markup characters. I want this XML copied onto the
result tree. Conceptually, I want to parse the XML and copy the resulting
nodes to the result tree. But if the result tree is being serialized to XML,
I don't mind the processor being clever and bypassing the parse/serialize
operations by copying the raw XML straight to the serial output file."

That doesn't deal with the HTML variant of the problem, though ....

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list