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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


Subject: [ubl-ndrsc] [Fwd: [ubl-comment] DateTime - A Class Derivation]


Folks-- I am assuming that we're treating the date/time paper as an NDR 
paper, and that this comment should therefore be put into our issues 
spreadsheet.  Gunther, can you please write up the necessary row(s) and 
supply them to Mavis for inclusion in the spreadsheet?

	Eve

-------- Original Message --------
Subject: [ubl-comment] DateTime - A Class Derivation
Date: Thu, 11 Jul 2002 13:35:24 -0400
From: "Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>
To: ubl-comment@lists.oasis-open.org



Comments from Bob Miller on OASIS Position Paper: Date and Time Expressions
Proposal 04, 28. June 2002

Good People,

We humans sure have a way of taking a simple thing like time and making
it complex!

I've tried my best to reverse this human process, thus far to no avail.
I fostered adoption of Metric Time (in truth, I was just trying to get
even with the Europeans for pushing a number of other metric measures at
us.)

Just two of the many benefits of metric time:
1) Companies have wished their employees would work seven days a week;
employees have wished that every weekend was a three day weekend.  The
metric week (ten days) can satisfy both wishes!

2) Seems everyone has wished for an extra hour in every day.  This one
is a little bit tough, as days are divided into tens and hundreds of
units.  But just to ease the conversion to metric time, we could define
a 'metric' hour as four centidays, and presto, we have that extra hour
in every day.

But I digress ...

In my opinion, there is need only for one conceptual representation for
time, which measure consists of a start and end time (a range).  All
these other expressions found in the position paper are derivable from
the one measure:

Range:   A time range having a start point in time in some degree of
precision, extended by nils to the maximum degree of precision
supported, and an end point in time in the some degree of precision,
extended by nines (in base 10) to the maximum degree of precision supported.

In formal terms, DateTimeRange is the base Class from which all other
Date/Time measures are derived.  The DTR class defines properties
startOfRange, endOfRange, maximumPrecision, precision, and formatType.
The DTR class defines processes to manipulate, store, encode, decode,
import, and export values of the class.  Note that the behavior of DTR
processes may be dependent on the class instance property values.

Subclasses of  the DTR class constrain properties of the class, and so
affect the behavior of processes associated with the parent class.

Consider two DTR instances, one of formatType "DateTime", and one of
formatType Duration.  Consider also a DTR process invoked by Operator
'+', such that the result of the operation was of format type DateTime.
Or consider two DTR instances, each of formatType Date, in which the
overloaded '+' operator returns a DTR instance of formatType "Range"

A Duration can be represented by fixing startOfRange to zero.
DurationInSeconds can be represented by a subclass of Duration in which
formatType="Seconds".


If this approach is adopted, a single consistent model for Date and Time
Expressions is assured.  Yes, there is still a need to define the base
DTR class, its properties, processes, and process behaviors.  And yes,
there still is a need to define the sundry subclasses that simplify the
use of the DTR class by 'fixing' or otherwise constraining properties of
the parent class.

I am aware that at least one C++ Class library chose to implement
Duration (TimeSpan) and Time (TimeInstant) as two distinct classes, and
chose not to implement a TimeRange class.  This leads to the definition
of more processes than the approach I suggest, though it is clearly
viable, just as the approach taken in the position paper is clearly
viable.  So I understand that the approach I suggest is but one of
several viable approaches.  I just happen to feel that TimeSpan,
TimeInstant, and TimeRange are closely related one to another, and the
representation I recommend makes explicit that relationship through
class hierarchy.

Cheers,
             Bob Miller


-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com



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


Powered by eList eXpress LLC