W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2015

[Bug 28632] New: map:merge and timezones

From: <bugzilla@jessica.w3.org>
Date: Wed, 13 May 2015 19:50:16 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-28632-523@http.www.w3.org/Bugs/Public/>

            Bug ID: 28632
           Summary: map:merge and timezones
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Functions and Operators 3.1
          Assignee: mike@saxonica.com
          Reporter: josh.spiegel@oracle.com
        QA Contact: public-qt-comments@w3.org
             Group: XSLXQuery_WG

>From the definition of map:merge:

"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

The definition of "same key":

"Within a map, no two entries have the same key. Two atomic values K1 and K2
are the same key for this purpose if the relation deep-equal(K1, K2, $UCC)
holds, where $UCC is the Unicode codepoint collation"

First, deep-equal is context-dependent so map:merge must also be
context-dependent.  Currently map:merge is marked as "context-independent".  
The same applies to map:put.

Second, I think the map:merge definition should be more specific about what
happens when timezoned and non-timezoned values are merged.  For example:

  let $without_tz := xs:dateTime('2015-04-08T01:30:00') 
  let $with_tz := adjust-dateTime-to-timezone($without_tz, implicit-timezone())
    map:merge( map { $without_tz : 1 }, map { $with_tz : 1 } )

Note the maps being merged have the "same-key".

Does this query:

(1) Return a map having a key with a timezone
(2) Return a map having a key without a timezone
(3) Either 1 or 2
(4) Raise an error

The answer also impacts map:put:

"The effect of the function call map:put($map, $key, $value) is equivalent to
the expression map:merge(($map, map:entry($key, $value))). "

Whatever the answer is, I think it should cover what happens in the case where
a sequence of maps with timezoned and non-timezoned values are merged. 
Combining any two maps in the sequence might cause FOMP0001 even if the end
result has only timezoned or non-timezoned values.  It would be nice if the
following expressions are made to be equivalent:

   merge((m1,m2,m3)) === merge((m1, merge((m2,m3)))

One solution:

- It is an error if there exist two maps in the input such that one has keys
with timezones and one has keys without timezones (even if the result would not
have both types of keys)

- Specify that when multiple entries have the *same key* the entry from the
last map in the input sequence is used (instead of just the value).  This is
still relevant for numeric keys

I think this makes it so:
 (1) map:merge and map:put always raise an error if their arguments contain
both keys with timezones and keys without timezones
 (2) map:get, map:remove and map:contains will adjust keys without timezones
based on the dynamic context timezone, if necessary (see deep-equal)

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 13 May 2015 19:50:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:54 UTC