Quoting Michael Kay <michael.h.kay@xxxxxxxxxxxx>:

[...]

> 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