This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: use cases for d-o-e
- From: roger dot day at globalgraphics dot com
- To: xsl-list at lists dot mulberrytech dot com
- Date: Wed, 9 Jan 2002 14:54:00 +0000
- Subject: Re: [xsl] use cases for d-o-e
- Reply-to: xsl-list at lists dot mulberrytech dot com
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