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

Subject: RE: [xsl] xsl:copy-of O.K. on RTF, but nothing on <EMPTY/> element content (?)
From: "William Reilly" <wreilly@xxxxxxxxxxx>
Date: Mon, 5 May 2003 21:28:55 -0400
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.
William Reilly
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 ?) ?)


> >> 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

> 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.



 XSL-List info and archive:

Current Thread