Many thanks, Mike, for helping confirm some assumptions.
Yes, XSLT 2 ought to help re: RTF & Etc.
(Your mentioning of looking out for xsl:key and recursion gives me more food
for thought...)
Thanks again for your responses.
Best,
William Reilly
wreilly(_at_)digitas(_dot_)com
Boston, Massachusetts U.S.A.
=============================================
Date: Mon, 5 May 2003 10:56:58 -0500
From: "Mike Haarman" <mhaarman(_at_)infinitecampus(_dot_)org>
Subject: Re: [xsl] xsl:copy-of O.K. on RTF, but nothing on <EMPTY/> element
content (?)
- ----- Original Message -----
From: "William Reilly" <wreilly(_at_)digitas(_dot_)com>
is there a string-based 'test' that would catch the (admittedly unusual)
condition of EECO-NW? ("Empty Element Content Only - NO Whitespace") e.g.
<markup><img src="pic.gif"/></markup>
I think the answer is No.
I think you're right.
have no content of string values, this is why no string test will find
anything there.
(And I guess you would only get at the attribute values if you
explicitly
ask for them (XPath ?) ?)
Yup.
is it reasonable to assert that one can do without the use of
'xsl:for-each select=', and can achieve everything one needs within
the 'select=' attribute of 'xsl:variable' and 'xsl:apply-templates' ?
The question is more nuanced than that, but it is true that the moment I find
myself nesting xsl:for-each I begin to wonder if I might be approaching the
problem incorrectly and I look out for an opportunity to exploit recursion or
key().
If this assertion is (reasonably) the case, then I guess I can
(reasonably)
expect to be able to avoid creating variables by way of RTF, and can
make
them instead the preferred way of 'xsl:variable select=' statements.
Yes?
FWIW, XSL 2 proposes to eliminate the notion of an RTF altogether, IINM.
hth,
Mike
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list