Re: [xsl] Disable output-escaping

Subject: Re: [xsl] Disable output-escaping
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Tue, 25 Jan 2005 12:29:10 -0500
At 10:10 AM 1/25/2005, you wrote:
>>>>> "Michael" == Michael Kay <mike@xxxxxxxxxxxx> writes:

    Michael> Although d-o-e is deprecated and may not work in all
    Michael> environments, copying unparsed HTML from a source file
    Michael> directly through to the serialized output of the
    Michael> transformation is one of the more respectable use cases
    Michael> for it.

No use of a deprecated facility can be considered respectable.
If there are use cases that require this facility, then it should AT
THE VERY LEAST, not be deprecated, and perhaps should be compulsory.

I can't speak to the issue of what "deprecated" should mean or what should be respectable, but I think it's worth noting, again, that the problems that come with d-o-e are all related to the fact that, unlike almost everything else you do in XSLT, what this feature controls is the serializer that writes the output to a file, not the processor that generates the output (the "result tree") to begin with.


A reason it is optional is that serializers are optional, and if an implementor builds an engine with no expectation that the result tree will be written out to a file, how is it to be handled?

As to whether it's "respectable", I find in my own work that it's worth considering whether the application of disable-output-escaping in question

* really needs to use the serializer to solve the problem
  (often there's a better solution in XSLT)
* respects the fact that it introduces dependencies on (a) a processor
  that implements d-o-e, and (b) the invocation of a serializer to
  write the results (i.e. you can't just pass the tree along) -- in
  practice this often means "won't work client-side in Mozilla"
* encapsulates the logic sufficiently to mitigate these dependencies,
  to the extent possible (on the rare occasions I've resorted to d-o-e
  I've kept it separate from the main stylesheet, as a pre- or post-
  process) -- this eases maintenance and reuse

All this having been said, I agree with Mike that it can be useful to undo the damage caused by having escaped markup inline (or the equivalent in the case Mike cites), which you need to recover (whether it's putatively HTML or XML). I don't know if it's respectable, but that kind of process by its very nature demands a serializer.

Cheers,
Wendell


====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================

Current Thread