[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Esoteric XSLT/FXSL question - foreach versus map

Subject: RE: Esoteric XSLT/FXSL question - foreach versus map
From: Justin Johansson <procode@xxxxxxxxxxx>
Date: Thu, 29 May 2008 23:43:43 +0900
RE:  Esoteric XSLT/FXSL question - foreach versus map
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.