This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: disable-output-escaping


At 07:43 PM 12/3/01, Mike Brown wrote:
>Wendell Piez wrote:
> > 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).
>
>My experience with developers who are well-versed in other languages but
>not in XML is that they don't see any compelling reason to maintain such a
>markup/text distinction. There is really nothing wrong with wrapping HTML
>in XML; this is not indicative of poor application design.

I agree with this: there's nothing wrong with it in the general case, and 
whether it's poor application design really depends on other factors.

But note I didn't say "wrapping HTML in XML" but "ill-formed HTML wrapped 
in XML". That is, there's a distinction between an application that does:

<chapter>
<h1>Chapter One</h1>
<p>It was <i>a dark and stormy night</i> and ...</p>
</chapter>

where the contents of <chapter> is well-formed (X)HTML, and

<chapter>
<![CDATA[
<h1>Chapter One</h1>
<p>It was <i>a dark and stormy night</i> and ...
]]>
</chapter>

True, in the second case we can still get the HTML in our output (if we 
write a file using disable-output-escaping). And sometimes this may be the 
only or best way to do it (i.e. wrap your HTML in CDATA and treat it as 
text). Most of the time, however, it should be possible to maintain the 
markup/text distinction by following the syntax rules (here, XML 
well-formedness) that make that distinction possible -- running HTMLTidy or 
otherwise fixing any broken HTML before we shovel it in. The advantages of 
doing it this way are considerable.

>  The problem is
>merely that they view their intended output as a pastiche of strings, and
>XSLT as instructions for generating those strings, whereas they should be
>viewing their output as the serialized form of what is essentially a
>single XML document that was created one abstract node at a time.

This is a nice way of phrasing exactly what I mean. Markup is not text: 
instead, it is a notation for or representation of something extra-textual 
-- the structure of abstract nodes.

Anyway, this is edging into not being an XSL topic anymore (though you 
should still feel free to criticize on- or off-list :-).

Cheers,
Wendell

> > 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.
>
>I prefer to look at this as a matter of XSLT 1.0 was simply not designed
>to output a document type declaration with an internal subset -- just as
>it was not designed to output references to entities, entities that are
>likely to be the only things declared in the internal subset. So in my
>opinion, there is no greater justification for using
>disable-output-escaping to write a <!DOCTYPE> with an internal subset than
>there is for using it to write an entity reference. It's still a hack.
>
>    - Mike
>____________________________________________________________________________
>   mike j. brown, fourthought.com  |  xml/xslt: http://skew.org/xml/
>   denver/boulder, colorado, usa   |  personal: http://hyperreal.org/~mike/
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


======================================================================
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]