Subject: Re: [xsl] use cases for d-o-e From: roger.day@xxxxxxxxxxxxxxxxxx Date: Wed, 9 Jan 2002 14:54:00 +0000 |
FWIW, and I'm just a person on the top of a Clapham Omnibus, if it's gotten rid of, there should be replacements - particularly for 4, which has recently bitten me. That's not an abuse - that's a workaround. However, isn't this covered by http://www.w3.org/TR/xslt20/#xml-output, Appendix F Representation of Lexical XML Constructs (Non-Normative)? So cases 3 and 4 should be fixed in XSLT 2.0 implementations....I think. I'll retreat in embarrassed silence if I'm wrong. Roger At 09/01/2002 14:27:59, Joerg Pietschmann <joerg.pietschmann@xxxxxx> wrote: # 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, Elliotte Rusty Harol | Thread | RE: [xsl] use cases for d-o-e, Hunsberger, Peter |
RE: Regular expression functions (W, Michael Kay | Date | Re: [xsl] use cases for d-o-e, David Carlisle |
Month |