This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Fixing <b>
- From: naha at ai dot mit dot edu
- To: xsl-list at lists dot mulberrytech dot com, Michael Kay <michael dot h dot kay at ntlworld dot com>
- Date: Thu, 28 Mar 2002 08:58:59 -0500 (EST)
- Subject: RE: [xsl] Fixing &lt;b&gt;
- References: <000a01c1d636$4edf9c60$6501a8c0@pcukmka>
- Reply-to: xsl-list at lists dot mulberrytech dot com
Quoting Michael Kay <michael.h.kay@ntlworld.com>:
[...]
> 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 suggests that there should be a way to bring these things in as
document fragments rather than as text. A lazy parsing mechanism
could provide the efficiency you suggest. I suppose that's much
more work for the implementor though than d-o-e is.
> That doesn't deal with the HTML variant of the problem, though ....
Alas, no.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list