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

[Bug 29622] [XQ31] Atomization in Postfix Lookup, Unary Lookup

From: <bugzilla@jessica.w3.org>
Date: Tue, 07 Jun 2016 19:24:37 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29622-523-Uq2i1qqQ79@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29622

--- Comment #3 from Michael Kay <mike@saxonica.com> ---
(In reply to Jonathan Robie from comment #2)
> I assume you want this for both maps and arrays.  If I understand this
> correctly, it would allow sequences of keys in either case:

No, I don't think that's an accurate description of the proposed change. 

(1) array:get($K) and map:get($K), as well as $A($K) and $M($K), all still
require $K to be a single atomic value. 

(2) the lookup operator $A?$K and $M?$K already allows $K to be a sequence of
atomic values.

What is changed is that in a lookup operator, $K is atomized as a whole, rather
than being atomized item-by-item. This brings it into line with all other
operations that expect a sequence of atomic values as an argument.

For example, suppose that @IDREFS is an attribute node of type xs:IDREFS with
value "A B C D" -- that is, its typed value is ("A", "B", "C", "D").

And consider $M, a map {"A":1, "B":2, "E":5}

Under the current rules, $M?(@IDREFS) is an error because it translates to 

map:get($M, ("A", "B", "C", "D"))

Under the proposed rules, the same expression returns (1, 2), because it
translates to

("A", "B", "C", "D") ! map:get($M, .)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 7 June 2016 19:24:40 UTC

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