[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: use cases for d-o-e

Subject: RE: use cases for d-o-e
From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx>
Date: Wed, 9 Jan 2002 15:01:51 -0000
php insert entity into doctype
The new unparsed-text() function in XSLT 2.0 is (I fear) going to trigger a
lot more use of d-o-e as people load chunks of unparsed HTML into their
transformations. Sigh.

Mike Kay

> -----Original Message-----
> From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Joerg
> Pietschmann
> Sent: 09 January 2002 14:28
> To: XSL List
> Subject:  use cases for d-o-e
>
>
> Jeni Tennison wrote: [in some other thread]
> > However, for all the complaints that
> > we make about people using disable-output-escaping, we
> rarely suggest
> > that it should be removed from the language just because people who
> > don't know any better use it inappropriately.
>
> Ok, i'll bite.
> So far, i'm aware of the following (ab-)uses of d-o-e
> 1. Process data which got as a string into the XSLT processor but is
>  really marked up data. This includes simple insertion into the result
>  tree. Usually, the string is read from a data base or has been CDATA
>  in a source XML document.
> 2. Produce a result document which looks like XML or HTML at a cursory
>  glance but actually isn't, like PHP or ASP source.
> 3. Insert entity references into the result.
> 4. Insert DOCTYPE declarations with an internal subset into
> the result.
>
> Does somebody know of uses which are not completely theoretical and
> don't fit in one of the categories above?
>
> The first use appears often enough that it can't be easily.
> Two solutions
> without d-o-e:
> - Use document with the data: protocol, which is already well
> specified:
>  document(concat('data:content=text/xml;encoding=ISO-8859-1;',$data)
>  (Hope i got it right)
> - Get a XPath parse function
>  xf:parse('text/xml','ISO-8859-1',$data)
> What's your opinion:
> - Is mandating support for the data: protocol a good idea?
> - Should we have a parse() function instead?
> - Should one or both be mentioned in the standard but made an optional
>  feature of the processor (but every one who likes being taken serious
>  implements it anyway :-)?
> The advantage of avoiding d-o-e for this use case is obviously that it
> works even if the result is not serialized, for example when a browser
> renders directly form the tree generated by the XSLT processor.
>
> The second is a somewhat harder nut to crack, but d-o-e can be avoided
> by setting output method to "text" and doing the serialization of
> elements by hand. Actually, the usual practice of setting the output
> method to xml or html *is* incorrect, it suggests that the output is
> XML (or HTML) which it actually isn't. Furthermore, PHP and ASP
> processor can't be fed with a XML tree anyway, as far as i'm aware of.
> The text output method could be made easier to swallow in
> XSLT 2.0, the
> stylesheet writer could construct a result tree in a variable as if he
> was constructing an XML tree, and then apply a generic template set
> imported from a library to this tree:
>   <xsl:import href="serialize.xsl"/>
>   <xsl:template match="/">
>    <xsl:variable name="result">
>      <!-- insert processing here -->
>    </xsl:variable>
>    <xsl:apply-templates select="$result" mode="serialize"/>
>   </xsl:template>
> So, for this purpose i expect we could drop d-o-e too.
>
> Case three: the most usual case is generating entity references which
> expand to character references. I don't think it is
> unreasonable to tell
> the perpetrators just not doing it.
> I know there are members of this list claiming that the possibility to
> output entity references referring to more complex stuff is essential
> to their work. Well, i'll just ignore this. :-)
>
> Case four: This came up only once so far. Don't know what to
> do about it.
> I'm not very happy with the solution as the output method has
> to be set
> to text while it's really XML (sort of opposite of case 2).
>
> Poll: Who does agree we can drop d-o-e without making too much
> customers unhappy? Who does not, and why not?
> NAG members are not allowed to invoke case three to thwart
> the proposal!
>  :-) :-)
>
> Regards
> J.Pietschmann
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.