Subject: RE: [xsl] use cases for d-o-e From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx> Date: Wed, 9 Jan 2002 15:01:51 -0000 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] use cases for d-o-e, naha | Thread | Re: [xsl] use cases for d-o-e, Elliotte Rusty Harol |
Re: [xsl] use cases for d-o-e, David Carlisle | Date | Re: [xsl] xsl architecture issue, Mattias Konradsson |
Month |