For Each in XSL

Subject: For Each in XSL
From: "Livingstone, Stephen" <Livinsb@xxxxxxxxxx>
Date: Tue, 16 Feb 1999 09:45:03 -0000
		<a>ADO 2.0</a>
		<a>ASP 2.0</a>

This might be pretty simple, but I can't seem to get the values of the
chilren of the <node.a> node.

I only ever seem to get the first value. Does anyone know what I should


Steven Livingstone BSc MSc GradInstP
Corporate Systems Development (TCN)
Royal Bank Of Scotland.
> *: mailto:livinsb@xxxxxxxxxx
> *:  +44 0131 523 4354 [x24354]
Networking Technical Associates,
Glasgow, Scotland.
> *: mailto:ntw_uk@xxxxxxxxxxx
> *: +44 07771-957-280
> -----Original Message-----
> From:	Didier PH Martin [SMTP:martind@xxxxxxxxxxxxx]
> Sent:	Monday, February 15, 1999 10:32 PM
> To:	xsl-list@xxxxxxxxxxxxxxxx
> Subject:	RE: CSS and XSL
> *** Warning : this message originates from the Internet ****
> HI Sinon,
> <YourComment>
> By the way, did anyone read the 'worse-is-better' article?  (It's at
>  It sums up a lot of the
> problems we've been talking about here quite nicely, though as an
> upstate
> New Yorker I'm not completely fond of identifying myself as a New
> Jersey
> sympathizer.
> </YourComment>
> <Reply>
> I read the article with great interest. It does gives fuel to the fact
> that
> XSL "transformation" module should be separated from XSL "formatting"
> module
> :-)
> On the CSS thing. I agree that some proposed construct are quite
> complicated
> for human to write and obviously CSS is, considering the human facets,
> a lot
> more easier to write and understand.
> What is contrary to the New philosophy however is to have a style
> property
> that has to be parsed with different constraint than the other
> properties.
> It would be easier to have a kind of object/property set thing. An
> object
> being marked up and having its property set expressed in the same
> manner. A)
> it is easier to implement because you have only one parsing rule B)
> easier
> to explain, because it is more obvious than saying bla bla bla except
> this
> property that... bla bla. We bring an exception in the panorama. This
> said,
> the only reasonable motive that I see why we would have a style
> property
> expressed that way is for a retrofit reason. And for the first release
> of
> HTML+CSS(XML) (named voyager) it seems reasonable (there is legacy out
> there). But for SVG I don't understand because there is no legacy. In
> this
> last case, we should have more the object/property set stuff with a
> simple
> XML syntax because there is no retrofit to do - there is no legacy.
> So, for
> HTML+CSS, I guess we don't have any choice, because of the legacy, to
> have
> the style property and a embedded parsing rule different than XML
> which in
> this case act as a container format. For XVG that's a different story
> because, as soon as a SVG rendition tool is available I can use SVG
> for
> rendition instead of HTML+CSS or in complement to HTML+CSS. If SVG has
> an
> easy structure and an easy syntax (i.e XML) then the task is easy to
> implement. If, however SVG has more than one syntax embedded in the
> other
> the implementation is harder and as said in the article you mentioned,
> we
> loose in the process. I agree on the fact that we should keep in mind
> two
> principles: modularity and simplicity. These are the key success
> factors.
> </Reply>
>  XSL-List info and archive:

This e-mail message is confidential and for use by the addressee only.  If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer..

'Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent.'

 XSL-List info and archive:

Current Thread