OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: "solution" to Work Item 23



[I'm sorry this is so late, but it had dependencies on other people, and
I wanted to make sure that we got it right...]

Wayyy back, Steve Hanna and I found some problems with how XACML deals
with time, date, and dateTime. Specifically, the problems involve time
zones [1], implicit assignment of time zones, and ordering. At the time,
we proposed two items that together should fix the problems: use XQuery
functions for all equality and comparison checking, and define a new
time-in-range function for determining if one time falls between two
others. The second solution is already in the spec, and does solve a
very real use case. The first item, however, required a little more
thought.

XQuery defines equality and comparison functions for date, time, and
dateTime. XACML is currently using the equality functions, but not the
comparison functions. For comparison, we're currently using XMLSchema,
which doesn't define specific functions but does define ordering. Of
course, when a timezone is only included in one of the two parameters to
a comparison function, the ordering is only partial, so some cases are
decidable and others are indeterminate. This is probably the right
behavior for time, especially with the addition of a time-in-range
function, because trying to add timezones and normalizing the two
parameters causes some wierd situations. For date and dateTime, which
exist on an infinite timeline and not a 24-hour loop, it's another
matter.

For instance, if I say something like "is April 6th, 2004 before the
current date" I expect to always get an answer. If the current date
includes a timezone, however, this is a partially ordered question, and
in some cases will be indeterminate. Should we expect users to include
timezones on all dates? Of course not, since people don't think about
dates having timezones. I raise this issue because, based on our
previous thread about date/time/dateTime, I'm not sure that everyone
knows how this works. In general, I know that I find this topic quite
confusing :)

So, here is what I think should happen:

  1. The definitions for date-equal, time-equal, and dateTime-equal,
     as well as the date, time, and dateTime datatypes, should be left
     as-is.

  2. The definitions for the 4 time comparison functions should be left
     as-is, but the following clarifying text should be added: "Note
     that it is an error to compare a time without a timezone to a time
     with a timezone, so if you need this kind of functionality, use
     the time-in-range function." From what I know of the new XMLSchema
     specification, this is the correct behavior.

  3. The definitions for the 4 date comparison functions, and the 4
     dateTime comparison functions, should change to refernce the
     cooresponding functions in XQuery ([XF] in our references section).
     This will do the right thing in regards to assigning timezones and
     will eliminate all indeterminate cases (so, in other words, it will
     provide the functionality that I think most people expect). I also
     think we should include the following clarifying text: "Note that
     for parameters without a timezone, an implicit timezone is assigned
     as defined in [XF]." You can still include explicit timezones if
     you want.

What exactly does this gain us? For one thing, it makes our handling of
date, time, and dateTime much clearer. For another, it does away with
any indeterminate evaluation cases. I can't find any discussions in the
past that suggested a preference for errors in all partially-ordered
cases, but if I've missed that please point me in the right direction.

Thoughts?


seth


[1] Yes, all three datatypes include timezones. I can't think of many
use cases where a date would need a timezone, but all the specifications
referenced support this.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]