Re: [xsl] XSLT repetition constructs

["Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

> On 6 Mar 2019, at 16:15, Dimitre Novatchev dnovatchev@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Wed, Mar 6, 2019 at 5:01 AM John Lumley john@xxxxxxxxxxxx
> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>
>>> All of these are *mapping" operations, like the map function in
>>> Haskell. These have nothing to do with repetition.
>>
>> Note that the XSLT3.0 specification does actually describe these under a
>> chapter heading "Repetition".....
>>
>
> Then this is a mistake in the specification -- time for errata.
> Repetition implies time passing during the transformation and there is
> no notion of "passed time" or time-ordering of execution in XSLT.


In legal contracts, and I think also in specifications, the choice of words in
section headings is non-normative; they are there purely to enable you to find
your way to the right section.

In editing the spec I actually tried quite hard to remove words that have
temporal connations, but it's remarkably difficult to achieve. For example,
the word "after" appears 185 times and "before" appears 141 times, often with
a sense of time ("are automatically used to validate all source documents
before they can be supplied as input to a transformation"). The keywords
"when" and "then" have a temporal sense for many readers (rather than merely
suggesting logical implication), and there are many other examples ("a newly
constructed node", "a sequence that is already sorted", "at the end of the
process").

The word "repetition" to me is no more temporal than "when" and "then", but I
guess if you look at the dictionary definition, it's explained in temporal
terms.

English is very short of words that can be used to convey logical sequence or
repetition without temporal connotations, and if we refrained totally from
such words, the spec would be unreadable.

But it's come a long way since XSLT 1.0, which used phrases like "after the
instantiation of the instruction is complete, the current node and current
node list revert to what they were before the instruction was instantiated." I
think there are very few places where we now specify semantics in terms of
stateful algorithms.

Michael Kay
Saxonica