- From: Dimitre Novatchev <dnovatchev@gmail.com>
- Date: Mon, 24 Apr 2023 15:12:40 -0700
- To: Norm Tovey-Walsh <norm@saxonica.com>
- Cc: public-xslt-40@w3.org
- Message-ID: <CAK4KnZe2OKJRHUNUdTzHPkU9ZfUUWi31bvcMQz6wW6GT_ZsXhw@mail.gmail.com>
> Unless someone objects in the next day or two, I propose to merge it > without further discussion I have these observations: 1. In https://qt4cg.org/pr/449/xpath-functions-40/autodiff.html#map-composition-decomposition it is said that: " It is often useful to decompose a map into a sequence of entries, or key-value pairs " This is still rather ambiguous and confusing to me, and this might be the reason why I thought that "entry" is a synonym of "key-value pair". This ambiguity can be removed by changing the text to: " It is often useful to decompose a map either into a sequence of entries, or into a sequence of key-value pairs " Or even better, move the definitions at the very front of this section, before the defined concepts are referenced in the text. ============================================================================================= 2. In the table with all functions on maps for map:values the description is: "Returns a sequence containing all the values present in a map, in unpredictable order." At the same time, for map:keys it says: "*Returns a sequence containing all the keys present in a map*". Note that in the latter the phrase "*in unpredictable order*" is missing. This could confuse the reader that the keys are returned in some predefined order. This can be fixed by adding the missing phrase. ============================================================================================== 3. There are 2 functions that return entries: *map:entries* and *map:entry*, but only one function for pairs: *map:pairs*. We don't have a function: *map:pair* Is this an accidental omission, and if not what is the reason for this decision? Thanks, Dimitre On Mon, Apr 24, 2023 at 9:53 AM Norm Tovey-Walsh <norm@saxonica.com> wrote: > Hi folks, > > I’ve been trying to experiment with ways to streamline our work. Any > item discussed in a meeting carries with it a minimum amount of > overhead. I don’t want to impede discussion of items where it’s needed, > but if we don’t spend that overhead on items where it isn’t, we can get > more useful work done. > > In PR #449, Mike has applied the changes we requested during review of > PR #420. It has one approval and it looks fine to me. > > Unless someone objects in the next day or two, I propose to merge it > without further discussion. > > Be seeing you, > norm > > -- > Norm Tovey-Walsh > Saxonica >
Received on Monday, 24 April 2023 22:12:59 UTC