RE: Action 695 argument

> -----Original Message-----
> From: Dave Reynolds [mailto:der@hplb.hpl.hp.com]
> Sent: Wednesday, February 04, 2009 1:29 AM
> To: Changhai Ke
> Cc: RIF WG
> Subject: Re: Action 695 argument
> 
> Changhai Ke wrote:
> > Some comments below.
> 
> [A minor request but would it be possible to configure your mailer to
> block quote the text you are replying to? That makes it easier to
follow
> a thread like this.]
> 
> > -----Original Message-----
> > From: Dave Reynolds [mailto:der@hplb.hpl.hp.com]
> > Sent: Tuesday, February 03, 2009 3:10 PM
> > To: Changhai Ke
> > Cc: RIF WG
> > Subject: Re: Action 695 argument
> >
> > Changhai Ke wrote:
> >> Hello all,
> >>
> >>
> >>
> >> Per my action http://www.w3.org/2005/rules/wg/track/actions/695,
> > please
> >> read below my answer.
> >>
> >>
> >>
> >> During the F2F 12, it was proposed to replace xsd:dateTime
> >> (http://www.w3.org/TR/xmlschema-2/#dateTime) by owl:dateTime in RIF
> > DTB,
> >> because the former does not deal well with timezone (more precisely
> >> timezone is optional). I was against this replacement and my
argument
> > is
> >> the following. (Acknowledgement: I'm not an expert of date
> >> representation. Please correct if something is wrong).
> >>
> >>
> >>
> >> 1. Xsd:dateTime allows representing dates with or without a
timezone.
> >> The timezone in xsd:dateTime is necessarily UTC. Initially, if you
> > have
> >> a date without a timezone, you can easily represent it in
> > xsd:dateTime.
> >> If you have a date with a timezone, you can (must) convert it into
UTC
> >
> >> and store it in xsd:dateTime. So in terms of information
preservation,
> >
> >> this type does not have any weakness.
> >
> > The issue is that some applications, such as the examples given by
Gary,
> >
> > treat a dateTime without a timezone as if it were a dateTime within
the
> > timezone of the current Locale. This different from xsd:dateTime. If
you
> >
> > converted such a dateTime-in-local-timezone to either an
> > xsd:dateTime-in-UTC or xsd:dateTime-without-timezone then you are
> > changing the semantics.
> >
> > [Changhai] This is also my examples, see below. And when a date has
no
> > timezone, the timezone is just undefined, we don't have to assume
that
> > the timezone will be the local one. We just don't care, the running
> > engine will define the time zone, which will become the timezone for
the
> > dateTime.
> 
> No. The running engine must not "define the timezone" if is
implementing
> xsd:dateTime correctly. If it receives an xsd:dateTime without a
> timezone it has to treat it as such and apply the comparison and
> equality algorithms accordingly. If it converted it to a timezoned
> dateTime (using any timezone, including the local one) it would be
> violating the specs.

[Changhai] It is essential that the rule engine can interpret the
dateTimes it encounters in the rules, with or without timezones. As a
reminder, we saw that comparison between dateTimes without timezone is
possible and defined in the spec. Here it's important to understand that
rules, as a constituent of a decision service, is run in a BPM process
as a task. The BPM monitor is a container, while the rules are the
contents.

The BPM process defines all the parameters for the whole process, such
as the currency, the timezone, etc. Anything that is not well defined in
the rules (as a content) will find their exact meaning in the container.


As an interchange, the most important is to acknowledge the existence
and usefulness of dateTime without timezone. When the business person
expresses the restaurant rule (between 5:00 and 9:00 pm give 10%
discount), that rule is valid everywhere, for all the timezones. As a
rule, it is intrinsic. We cannot force business people to add a timezone
(if so, he will have to express the same rule for 24 timezones,
ridiculous!) This rule then gets to be deployed, to simplify let's say
the deployment scheme is that a specific rule engine takes care of a
time zone. The engine then knows what is its timezone and how to
interpret dateTimes without timezones that it encounters in the rules.

The engine can be initialized to work on its local timezone (for example
a server in NY to take care of EST), or the engine can be initialized
with another timezone (for example I start an engine in Paris to process
the timezone EST). This deployment scheme is the problem for the BPM
tools or scheduling tools, the rules (as a content) should focus on the
contents part, not the "environment" part.

> 
> >> 2. In general, it is simpler and straighter to keep XML types
without
> >> replacement. With the widespread of the web services, there are
> > already
> >> numerous utilities to manipulate xsd:dateTime. Moreover, W3C Schema
> >> group may fix this issue, and we'll benefit from it. Owl:dateTime
> > itself
> >> is also at risk (see: http://www.w3.org/TR/owl2-syntax/, search for
> >> "**Feature At Risk #3: /owl:dateTime/ name").**
> >
> > First, adopting a fixed xsd:dateTime-with-required-timezone would
indeed
> >
> > be preferable. The issue is one of timescale, do you propose
postponing
> > adoption of dateTime in RIF until XML Schema has been changed and
> > reversing our decision to use XML Schema 1.0?
> >
> > [Changhai] Not sure what you mean. For my part, I meant that we
should
> > leave xsd:dateTime in RIF and not try to fix it. W3C will fix this
(will
> > or will not, whatever), and OWL says that owl:dateTime is not
> > guaranteed. Double reason to wait for fixes from W3C and not to
> > anticipate unnecessarily.
> 
> The "fix" would presumably be the introduction of a new
> xsd:dateTimeWithRequiredTimeZone type. If RIF adopts xsd:dateTime it
> does not benefit from any such fix.
> 
> > Second, if you are happy to adopt the fixed
> > xsd:dateTime-with-required-timezone and if we agree that that is
> > precisely what owl:dateTime is then what is the problem with
adopting
> > owl:dateTime?
> >
> > [Changhai] My point is precisely that dateTime without timezone have
its
> > application. I thought that I expressed my point clearly.
> >
> >> 3. There are also use cases where the timezone information is
missing
> > or
> >> is irrelevant. For example, when you want to write a birth date
(eg:
> >> "12/20/1970"), you write it without a timezone. I don't know how
this
> >> can be represented in owl:dateTime, but it is straight to represent
it
> >
> >> in xsd:dateTime.
> >
> > Actually that is an xsd:date not an xsd:dateTime, they are different
> > primitive types. At the moment RIF is not proposing to adopt
xsd:date,
> > xsd:time, xsd:gYear etc.
> >
> > [Changhai] I don't understand your point. How do you represent
> > "12/20/1970" without a timezone? If xsd:date is not in RIF, then I
> > should represent it with xsd:dateTime, right?
> 
> No. This is a separate issue from the one about timezones but you
can't
> have an xsd:dateTime without a time component (or without a date
> component for that matter which your later example requires).  If you
> want to express these then you should request that RIF also require
> support for xsd:date and xsd:time.  The timezone issue still applies
to
> both of those.
> 
> > Precisely if I use
> > owl:dateTime, I will be thinking hard what will be the timezone,
while
> > initially there is no timezone concept. (A person born somewhere can
> > change timezone and have birthday locally).
> >
> >> If I write this production rule: "For any restaurant booking in
12/31
> >> between 5:00pm and 9:00pm, give a 10% discount". My rule does not
have
> >
> >> any timezone, it is intrinsic and can be applied to all the
locations.
> >
> >> Of course, the executing environment needs to be well set (for
example
> >
> >> there will be a rule engine for the east coast timezone, while
another
> >
> >> one will be for the central Europe), but the rule content itself
does
> >> not need to refer to any timezone.
> >
> > That is precisely the case I outlined above. You cannot use
xsd:dateTime
> >
> > for that because you are assuming that a non-timelined xsd:dateTime
> > corresponds to the current Locale timezone which it doesn't. If your
> > application assumes this convention, but sends the RIF rules to a
> > different application which does not make this assumption you will
get
> > incompatible results.
> >
> > [Changhai] We have a misunderstanding here. A date may not have a
> > timezone, and we don't have to care about it, at least from a
production
> > rule point of view. We make sure that the same date is restored on
the
> > other side, this is the role of the interchange. After this it will
> > happen what will happen.
> 
> Dates can have timezones and in some applications you care about this.
> If say a product will be shipped on 5/2/2009 but I ship 8 hours late I
> should not be able to claim I was still on time just because there is
> some timezone in the world where it was still 5/2/2009 when I shipped.
> This is true even in a production rule world :-)
> 
> 
> Let me try to be clearer. Let's take your example rule:
> 
>    For any restaurant booking in 12/31
>    between 5:00pm and 9:00pm, give a 10% discount
> 
> Set aside that you need xsd:date and xsd:time to represent this rule,
> (xsd:dateTime is not sufficient).
> 
> When the receiving rule engine runs this rule in a production rule
> setting then it presumably runs it over some working memory which
> contains a restaurant booking with a dateTime attached. In normal
> circumstances that will be a real timezoned dateTime (in the local
> timezone) - that's certainly what you'll get if you instantiate a Java
> Calendar object. Your rule, if it is implementing xsd:dateTime
> correctly, will be comparing a non-timezoned date and time constraint
> with a timezoned working memory value in which case it must use the
> "+/-14 hours" algorithm defined in 3.2.7.4 of [1]. On that basis the
> rule can never be satisfied. It doesn't express what you want it to.
> 

[Changhai] See my previous comment. Here we are manipulating 2 data:
The first is a dateTime from a rule, without timezone. 
The engine which attempts to use this dateTime (for example by creating
a Java object), has already been launched on a specific locale and
timezome, thus will create a perfectly defined dateTime by adding a
timezone. Another alternative implementation of the engine will be to
keep all the dateTimes without timezone, and perform computation and
comparison relatively between them.

A dateTime with timezone and one without, even unified under a same
type, should be considered as 2 different types. More exactly, the
relation operators are well defined, and I perfectly understand your 14
hours jetlag issue. Rules are not supposed to do comparison between
dateTime with timezone and without. How about a rule which compares a
temperature vs. a weight, they are all numbers? The primary
responsibility of the interchange is to restore the same information on
the other side, then the executing needs to do the rest.


> Dave
> 
> [1] http://www.w3.org/TR/xmlschema-2/#dateTime
>

Received on Wednesday, 4 February 2009 14:00:12 UTC