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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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


Subject: RE: [ubl-lcsc] Alan Stitzer Comments on DateTime


Title: Message
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 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 on 03 July, 2002,
08:46:44 PM Wednesday >>>



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 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 on 03 July, 2002, 01:47:05
AM Wednesday >>>


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>


To: 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




.


--
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





----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

.


-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142 



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