RE: [xsl] xsl:copy-of O.K. on RTF, but nothing on <EMPTY/> element content (?)

["William Reilly" <wreilly@xxxxxxxxxxx>]

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@xxxxxxxxxxx
Boston, Massachusetts U.S.A.
=============================================
 
Date: Mon, 5 May 2003 10:56:58 -0500
From: "Mike Haarman" <mhaarman@xxxxxxxxxxxxxxxxxx>
Subject: Re: [xsl] xsl:copy-of O.K. on RTF, but nothing on <EMPTY/> element content (?)

- ----- Original Message -----
From: "William Reilly" <wreilly@xxxxxxxxxxx>

> 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