This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: disable-output-escaping
- From: Wendell Piez <wapiez at mulberrytech dot com>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Mon, 03 Dec 2001 11:08:41 -0500
- Subject: RE: [xsl] disable-output-escaping
- References: <a0510031fb82da827c8ed@[192.168.254.19]>
- Reply-to: xsl-list at lists dot mulberrytech dot com
At 06:29 PM 11/30/01, Mike wrote:
>The real reasons are (a) that if you mix metaphors by generating part-tree
>and part-sequential-file, then your transformations are never going to be
>composable and reusable, and (b) that you'll never learn the power of the
>language if you start out by misusing it this way.
To reiterate and emphasize what Mike says, these two reasons for avoiding
disable-output-escaping are deeply entangled with one another. Writing your
markup as literals using d-o-e treats markup as if it were text, thereby
breaking the basic paradigm of the structured markup approach to text
processing, which is the source of its strength (as well as, occasionally,
its Achilles' heel): the distinction between text (data) and markup as
(despite appearances) fundamentally two different things.
It is significant that people most often try the d-o-e approach when they
are either (1) still naive about the way XSLT works, and projecting
mistaken expectations onto it (see Mike's (b)), or (2) trying to build an
application whose concept or design is already threatening the markup/text
distinction, such as handling ill-formed HTML markup wrapped in XML, or
trying to do "metamarkup" in some way (marking up markup). (1) is curable,
and (2) may sometimes be defensible, but it's often difficult to sort out
where a given developer is, and you might be guilty of both.
A third case such as Rick Geimer's writing the internal declaration subset
is the exception that proves the rule. Here, we'd like to write the output
as markup, but since XSLT doesn't give us facilities to manage and output
declarations as markup (strictly the DOCTYPE declaration with its contents
ought to be markup), one has no choice but to fall back on pretending it's
text.
Cheers,
Wendell
======================================================================
Wendell Piez mailto:wapiez@mulberrytech.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