[Bug 25375] New: [xslt 3.0] Maps and the implicit timezone

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug 25375] New: [xslt 3.0] Maps and the implicit timezone

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25375

            Bug ID: 25375
           Summary: [xslt 3.0] Maps and the implicit timezone
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: [hidden email]
          Reporter: [hidden email]
        QA Contact: [hidden email]

We say that two keys (in a map) are "the same key" if deep-equal(K1, K2, $UCC)
holds, where $UCC is the Unicode codepoint collation. We have therefore tried
to make the definition context-independent as far as collations are concerned.
However, deep-equal() still has a dependency on the dynamic context when it
comes to comparisons of date/time values with no explicit timezone.

The effect is that maps as currently defined cannot "cross timezone
boundaries"; a map that is perfectly OK in one (implicit) timezone may become
invalid, because of duplicate keys, when used in a dynamic context with a
different implicit timezone.

The complications become worse when maps are treated as functions, because we
now get all the issues concerned with higher-order functions that carry context
information in their closure.

Possible solutions:

(A) disallow maps from containing (as keys) date/time values with no timezone.
This can be done in several ways:

(A.1) using a timezoneless date/time value as a key is an error

(A.2) a timezoneless date/time value is converted to a value with timezone
using the implicit timezone at the point where the entry is added to the map.

(A.3) a timezoneless date/time value is converted to a value with timezone by
assuming UTC.

(B) treat values-with-timezone as being always not-equal to
values-without-timezone. The disadvantage of this is that it introduces yet
another equality operator to the system, and people would want other ways of
making use of this flavour of equality matching.

The least disruptive solution is probably A.2. But I would prefer a solution in
which map:get() is deterministic and context-independent, so that you never get
the situation where map:get() may or may not find something depending on the
context. I'm therefore going to propose A.3. Essentially, functions that accept
a key value (such as map:get() and map:new()) treat any timezoneless date/time
as being UTC; functions that return keys (such as map:keys()) always return
dates/times with a timezone.

--
You are receiving this mail because:
You are the QA Contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 25375] [xslt 3.0] Maps and the implicit timezone

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25375

--- Comment #1 from Michael Kay <[hidden email]> ---
Another little consequence of this problem: we say that in a MapExpr it's a
static error if two keys are the same, but we cannot determine whether two keys
are the same until we know the implicit timezone, and this is part of the
dynamic context.

--
You are receiving this mail because:
You are the QA Contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 25375] [xslt 3.0] Maps and the implicit timezone

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25375

Sharon Adler <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #2 from Sharon Adler <[hidden email]> ---
This bug needs to be discussed in the context of the Joint meeting.  MKay sent
note to Joint chairs requesting that this bug be put on the Agenda for the
Joint F2F in Hursley.

--
You are receiving this mail because:
You are the QA Contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 25375] [xslt 3.0] Maps and the implicit timezone

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25375

Jonathan Robie <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |[hidden email]
         Resolution|---                         |FIXED

--- Comment #3 from Jonathan Robie <[hidden email]> ---
The Working Group decided to resolve this bug as follows:

You can't mix dates/times with timezones and dates/times without timezones in
the same map - an error [err:DONTDOTHAT] is raised if an attempt is made to add
a key that does not obey this rule. For equality matching, the implicit
timezone is used, per the current language specification.

--
You are receiving this mail because:
You are the QA Contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 25375] [xslt 3.0] Maps and the implicit timezone

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25375

--- Comment #4 from Michael Kay <[hidden email]> ---
The XSLT 3.0 spec has been updated to apply this rule. (Work remains to be done
on the 3.1 specifications).

--
You are receiving this mail because:
You are the QA Contact for the bug.