Subject: RE: [xsl] Esoteric XSLT/FXSL question - foreach versus map From: Justin Johansson <procode@xxxxxxxxxxx> Date: Thu, 29 May 2008 23:43:43 +0900 |
Thanks folks for explanations. > Dimitre > There is ordering of the *results*, not of the application of the body > of <xsl:for-each> to the elements of the sequence. Yes, I understand. It was the result ordering that got me thinking about I/O monads controlling the sequential output (and boiling down to joins on multi-processor threads). Sounds like Colin has a take on managing this (parallelism) as well. > Michael Kay > The use of the English words "for each" is a mixed blessing. On the one > hand, it makes your typical user less uncomfortable than if it were named > xsl:map. On the other hand, it gives people the wrong impression that it is > procedural. Okay, I went away thinking that "for each" and "map" were synonyms but upon reflection me thinks that these terms/names are subtlely different. Refer your example <xsl:for-each select="S"> <instructions/> </xsl:for-each> The concept of "for each" means, at least to me, to do something and to produce a result (sequence) of zero or more items against corresponding items in the input sequence to "for each". "instructions" has a general result signature of item()*. Conceivably, the overall result could be the output of zero items for a non-empty argument sequence given to "for each". The concept of "map" however, generally suggests, say, a 1-N mapping of input items to result items as produced by the higher-order application of "instructions", N generally being a constant >= 1, certainly not variable and generally not zero either. In a "mapping" context, "instructions" has a signature like instructions ( arg as item()) as item() and not instructions ( arg as item()) as item()? as may be a use case for "for each". Trustingly this argument is clear enough to demonstrate the different between the notions of "for each" and "map". Now, for "for each" and "map" to be 100% tautologous, would, imho, require that (in the XPath environment) sequences allow "null" or the empty sequence to be a valid item within a sequence, or, in other words, sequences may contain nested sequences, including the empty sequence itself. As XPath has no notion of nested sequences, and, from my memory of the spec, null-ness is represented by empty-ness (i.e. sequences of exactly zero items). Accordingly, foreach and map are not quite the same thing when the XPath data model does not allow for nested sequences. Whether the omission of nested sequences from the XPath model was a good thing, a pragmatic thing, or a bad thing, I am not quite sure. Cheers Justin Johansson --------------------------------------------------- A horse with no name is called Lambda. What was the name of the town in the song? ---------------------------------------------------
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] stylesheet problem - X3D , Scott Trenda | Thread | Re: [xsl] Esoteric XSLT/FXSL questi, Colin Adams |
[xsl] stylesheet problem - X3D XSLT, j milo taylor | Date | Re: [xsl] stylesheet problem - X3D , Florent Georges |
Month |