RE: [xsl] Esoteric XSLT/FXSL question - foreach versus map

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

The concept of "for each" means, at least to me, to do something and to
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
(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
sequences, including the empty sequence itself.  As XPath has no notion of
sequences, and, from my memory of the spec, null-ness is represented by
(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.


Justin Johansson

A horse with no name is called Lambda.
What was the name of the town in the song?

Current Thread