At 10:10 AM 1/25/2005, you wrote:
>>>>> "Michael" == Michael Kay <mike(_at_)saxonica(_dot_)com> 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(_at_)mulberrytech(_dot_)com
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
======================================================================
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--