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: use cases for d-o-e


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@zkb.ch> 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


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