[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-lcsc] Alan Stitzer Comments on DateTime
So...
I'm not sure what has been happening so here is what I thought we had from
the original paper.
Gunther (and subsequently Mike) thought that using xsd:duration would be
the right way to go on this. I agree with Mike's comments on Tim's
comments -- (BTW, the source of those comments was Tim).
The ACORD "duration" consists of the tags you see below (minus
<RecurringDetails>.
<ContractTerm>
<StartTime>
<EndTime>
<StartDt>
<EndDt>
<Description>
<LocalStandardTimeInd>
<DurationPeriod>
<NumUnits>
<UnitMeasurement>
</DurationPeriod>
<RecurringDetails>
<NumUnits>
<UnitMeasurement>
<FrequencyCd>
</RecurringDetails>
</ContractTerm>
We had this set up to allow for a multitude of ways to express the length
of a contract. Risks have different characteristics. Some have a simple
start and end date and time, some do not have a specific start date, but
are only covered for a certain amount of time (say 30 days from an unknown
start date), some risk coverage starts only after a specific event takes
place and ends on a specific end date....the combinations go on and on.
If xsd:duration can help with these situations, I would be ok with that
scenario -- we (the insurance industry) can always extend what we need to
fit the industry's needs.
Just for fun, would someone post what xsd:duration looks like.
Regards,
____________________
Alan Stitzer
AVP
Marsh USA Inc.
1166 Avenue of the Americas
New York, NY 10036-2774
Phone: (561) 743-1938
Fax: (561) 743-1993
Internet: Alan.Stitzer@marsh.com
____________________
<<< Memo from gunther.stuhec@sap.com@Internet on 21 May, 2003, 04:04:53 AM
Wednesday >>>
gunther.stuhec@sap.com@Internet on 21 May 2003, 04:04 Wednesday
To: tmcgrath; Alan Stitzer
cc: ubl-lcsc
Subject: RE: [ubl-lcsc] Alan Stitzer Comments on DateTime
Hello all,
I guess, Mike and I defined the expressions for (a.) (Particular Point)
and (b.) (Duration) in our position paper well enough.
It is clear that we need for the particular point some additional
"representation terms", because this representation terms based on the
specific built-in datatypes for defining the particular point.
The expression for duration is not clear enough now. I made two
suggestions. In the first suggestion I using the CCT "Measure.Type" and in
the second suggestion I using the built-in datatype "xsd:duration". Both of
these suggestions have advantages and disadvantages. Due we realizing a
future based standard I prefer the "xsd:duration", because its much more
flexible and understandable by nearly every XML-Schema based parser.
Kind regards,
Gunther
-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Dienstag, 9. Juli 2002 04:14
To: Alan.Stitzer@marsh.com
Cc: ubl-lcsc@lists.oasis-open.org
Subject: Re: [ubl-lcsc] Alan Stitzer Comments on DateTime
whilst i feel that Alan's comments do not actually disgaree with the
position paper - i suspect that we are missing simplistic model of this
proposal.
is it actually saying that we need two expressions:
a. measure of point in time
and
b. measure of elapsed time ??
The 'Particular Point of Date and/or Time' is (a.)
The 'Duration' is (b.)
The 'Period' is either a combination of (a.) + (b.), (a.) + (a.) or (b.) +
(a.)
The 'Periodicity/Recurrent' is either:
- a series of (a.) within a (b.)
- a series of (Period) within a (b.)
- a series of (a.) within a (Period)
- a series of (b.) within a (Period)
- which seems to imply we need to define only expressions for (a.) and
(b.).
I think Alan's point is that when defining types higher than this we get
into a reusability versus complexity problem.
Alan.Stitzer@marsh.com <mailto:Alan.Stitzer@marsh.com> wrote:
Hi guys,
I will not be able to be there on Tuesday due to an internal Marsh meeting.
I do have some things to say about the date time, and have included them in
this email. I have already sent them to Gunther and Mike as part of the
document...
COMMENTS FROM ALAN STITZER
It is difficult to see from this document what you are recommending. I
think the options are all very well thought. ACORD is compliant (right
now) with ISO 8601 format. We did not use 8601 for duration because of
the complexity of what had to go into it.
When I submitted the ACORD "DURATION" entity from the DTD I was
expecting to see something like that come out of your exercise. What I
would like to see is something like this (and I am not an XSD guru by
any stretch of the imagination) so I am just going to put in an XML
stream of what I thought I was going to see:
<
br>
For instance (Don't worry about the tag names??) The tag <ContractTerm>
would be made up of a collection of other elements, start and end dates,
start and end times, an indicator for local time, a duration period, and
a recurring details section.
<ContractTerm>
<StartTime>
<EndTime>
<StartDt>
<EndDt>
<Description>
<LocalStandardTimeInd>
The basic information is start and end dates, times, a description (if
necessary ? to describe an event, for instance this is to take effect as
soon as the shuttle clears earth's atmosphere), and an indicator to show
that these same terms apply to the enterprise's entire operation across
the globe at the given date/time in that area.
<DurationPeriod>
<NumUnits>
<UnitMeasurement>
</DurationPeriod>
The duration period is used to express, say, 30 days, although 30 days
means nothing without something in the description. We find that in
insurance when a specific start and end time would not be possible to
pin down.
<RecurringDetails>
<NumUnits>
<UnitMeasurement>
<FrequencyCd>
</RecurringDetails>
The recurring details would take into account every nth "something".
You would not need a start/end date/time within that because it already
exists as basic information ? so all you have to specify is a number of
units, a unit of measurement, and a frequency.
</ContractTerm>
ajs
<<< Memo from tmcgrath@portcomm.com.au@Internet <
mailto:tmcgrath@portcomm.com.au@Internet> on 03 July, 2002,
08:46:44 PM Wednesday >>>
tmcgrath@portcomm.com.au@Internet <mailto:tmcgrath@portcomm.com.au@Internet
> on 3 Jul 2002, 20:46 Wednesday
To: Alan Stitzer
cc:
Subject: Re: [ubl-lcsc] Action Items for this week
it may be useful to post your comments to the discussion list so we can
debate them prior to next tuesday.
Alan.Stitzer@marsh.com <mailto:Alan.Stitzer@marsh.com> wrote:
Tim,
I have submitted my comments to Gunther and Mike about the DateTime
issues.
I have some pretty strong feelings about what they did, and unfortunately
I
cannot attend the meeting next week. I have some Marsh business that I
must attend to.
Is there anything we can do?
Thanks,
alan
<<< Memo from tmcgrath@portcomm.com.au@Internet <
mailto:tmcgrath@portcomm.com.au@Internet> on 03 July, 2002, 01:47:05
AM Wednesday >>>
tmcgrath@portcomm.com.au@Internet <mailto:tmcgrath@portcomm.com.au@Internet
> on 3 Jul 2002, 01:47 Wednesday
To: ubl-lcsc
cc: (bcc: Alan Stitzer)
Subject: [ubl-lcsc] Action Items for this week
As promised I have reviewed the action items in front of use and would
like to propose that we set the following goals...
Position Papers: There are many important issues in these three papers
that we ALL need to agree to and then move on with our work.
* Methodology (owners: Bob,Tim)
Can we all submit
comments prior to a final paper being presented for
acceptance on the 9th July meeting.
* Code/Identifier (owners: Sue, Mike)
Can we all submit comments prior to a final paper being presented for
acceptance on the 9th July meeting.
* Date/Time (owners: Gunther,Mike)
Can we all submit comments prior to a final paper being presented for
acceptance on the 9th July meeting.
also,
* Private vs Standard Identifier (owners: Frank, Mike, Gunther)
Lower priority, targeted for July 16th or 23rd.
Outstanding tasks:
* Order Response (Bill, Lisa)
Initial draft model to be presented on July 9th meeting
* Class Diagram (Frank, Gunther, Tim, Ron)
Initial draft diagram and position paper to be presented on July 16th
meeting. This may be a subset to demonstrate the principles being
applied.
* Actioning Disposition tasks (Various)
Lisa to condolidate during the week of 9th July. Tim to then apply
global changes (names, re-usable types, data type, alignment with
position papers, etc.) by the 23rd July
This means in 2-3 weeks we should have the makings of the next release
of the UBL Library. By the 30th July we should be able to consolidate
amd then approve this version. This would enable us to publish in the
first week of August in keeping with our schedule.
Such a tight schedule puts the requirement on us all to ensure we fulfil
the obligation set by the items against us.
--
regards
tim mcgrath
fremantle western australia 6160
phone: +618 93352228 fax: +618 93352142
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl> <
http://lists.oasis-open.org/ob/adm.pl>
To: ubl-lcsc@lists.oasis-open.org@Internet <
mailto:ubl-lcsc@lists.oasis-open.org@Internet>
cc: (bcc: CN=Alan Stitzer/OU=NYC-NY/OU=US/OU=Marsh/O=MMC)
From: tmcgrath@portcomm.com.au@Internet <
mailto:tmcgrath@portcomm.com.au@Internet>
.
--
regards
tim mcgrath
fremantle western australia 6160
phone: +618 93352228 fax: +618 93352142
To: Alan Stitzer/NYC-NY/US/Marsh/MMC@MMC
cc:
From: tmcgrath@portcomm.com.au@Internet <
mailto:tmcgrath@portcomm.com.au@Internet>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl> <
http://lists.oasis-open.org/ob/adm.pl>
.
--
regards
tim mcgrath
fremantle western australia 6160
phone: +618 93352228 fax: +618 93352142
To: tmcgrath@portcomm.com.au@Internet, Alan
Stitzer/NYC-NY/US/Marsh/MMC@MMC
cc: ubl-lcsc@lists.oasis-open.org@Internet
From: gunther.stuhec@sap.com@Internet
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]