RE: [xsl] use cases for d-o-e

["Michael Kay" <michael.h.kay@xxxxxxxxxxxx>]

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: [xsl] 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