W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2016

[Bug 29723] [FO31] map:merge

From: <bugzilla@jessica.w3.org>
Date: Tue, 19 Jul 2016 17:22:58 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29723-523-ojBdaoL1ri@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29723

--- Comment #2 from Michael Kay <mike@saxonica.com> ---
ACTION A-650-02: Action on Mike Kay to write a proposal for adding options to
map merge (use-first, use-last, reject, combine, don’t care).  

Proposal (in addition to deleting the redundant sentence mentioned above).

Add an optional second argument to map:merge, so there are two signatures:

map:merge($maps as map(*)*) as map(*)
map:merge($maps as map(*)*, $options as map(*)) as map(*)

<quote>
The effect of the arity-1 function is the same as the effect of the arity-2
function when an empty map is supplied as the value of $options.

The $options argument can be used to control the way in which duplicate keys
are handled. The ·option parameter conventions· apply.

The entries that may appear in the $options map are as follows:

Key     Value   Meaning

duplicates      Determines the policy for handling duplicate keys, when two or
maps in the value of $maps contain the *same key*. The required type is
xs:string. The default value is "use-first".

reject  An error is raised [err:FOJS0003] if duplicate keys are encountered.

use-first       If duplicate keys are present, all but the first of a set of
duplicates are ignored, where the ordering is based on the order of maps in the
$maps argument.

use-last        If duplicate keys are present, all but the last of a set of
duplicates are ignored, where the ordering is based on the order of maps in the
$maps argument.

combine         If duplicate keys are present, the result map includes an entry
for the key whose associated value is the sequence-concatenation of all the
values associated with the key, retaining order based on the order of maps in
the $maps argument.

unspecified     If duplicate keys are present, the effect is
implementation-defined; the implementation may choose one of the above
strategies for handling duplicates, or may choose some other strategy.

Informally, the supplied maps are combined as follows:

There is one entry in the returned map for each distinct key present in the
union of the input maps, where two keys are distinct if they are not the ·same
key·.

For any key that appears in only one of the input maps, the associated value
for that key in the result map is the same as the associated value in that
input map.

For any key that appears in more than one of the input maps, the associated
value for that key in the result map depends on the way in which duplicates are
handled, as described above.

The definitive specification of map-merge#2 is as follows. The result of the
function call map:merge($MAPS, $OPTIONS) is defined to be the result of the
expression

let $FOJS0003 := QName("......", "FOJS0003"),

$duplicates-handler := map {
  "use-first": function($a, $b) {$a},
  "use-last": function($a, $b) {$b},
  "combine": function($a, $b) {$a, $b},
  "reject": function($a, $b) {error($FOJS0003)},
  "unspecified": function($a, $b) {{#vendor:defined#}{}}
},

$combine-maps := function($A as map(*), $B as map(*), $deduplicator as
function(*)) {
    fn:fold-left(map:keys($B), $A, function($z, $k){ 
        if (map:contains($z, $k))
        then map:put($z, $k, $deduplicator($z($k), $B($k)))
        else map:put($z, $k, $B($k))
    })
}
return fn:fold-left($MAPS, map{}, 
    $combine-maps(?, ?, $duplicates-handler(($OPTIONS?duplicates,
"use-first")[1]))


</quote>

Change the example map:merge(($week, map{6:"Sonnabend"})) to illustrate the
various options:

reject -> error
use-first -> 6:"Samstag"
use-last -> 6:"Sonnabend"
combine -> 6:("Samstag", "Sonnabend")
unspecified -> result is implementation-defined.

Change the example of map:merge that appears under fn:collation:key.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 19 July 2016 17:23:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:01 UTC