[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (WSCALENDAR-124) WS-Calendarshould be able to express an open ended period, i.e. start time, but no endtime
[ http://tools.oasis-open.org/issues/browse/WSCALENDAR-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24403#action_24403 ]
Benoit Lepeuple commented on WSCALENDAR-124:
---------------------------------------------
Some thoughts following Friday's conf call:
The interval as defined by dtStart and Duration is fine, and it is worth using it for 2 other use cases:
1/ A zero-length duration called event in many automation fields, or milestone in project planning.
If we conclude on the fact that 0 is a valid duration, the case is quite easy to solve.
Maybe a duration of 0 should impact the inheritance mechanism. Maybe blocking it (if an interval is of duration 0, the duration can not overriden to something else than 0 by a parent gluon), but allowing to define a 0 duration in a gluon that would apply to children intervals not having the duration defined.
About dtEnd in this case: dtEnd = dtStart+Duration so with a 0 duration interval dtEnd is "simply" equal to dtSart.
2/ Toby's lime, is with no doubt an interval defined by a dtStart and a duration except that the duration will be known later. It is for real an interval, should be defined the same way than any other, I would not advise to create another type of element for this.
With the hypothesis that the duration can not be optional, the first issue is how to express the Duration. I would tend to say that we should make the Duration not optional but nillable, the Duration element being always present, but with no value in the lime case.
Another option would be to pick a particular value, for example, the minimum value of xs:DateTime or the maximum value. Picking the min value would probably be ok (easily testable and no side effect in the future); picking the max value may introduce yet another y2k series of bugs ?
The second issue introduced by the lime concept is that it is the first one where there is a particular need of identification of the interval when the further notice comes with the duration. First being able to correlate this interval coming with a duration, in addition to specifying in a very clear manner what should be the dtStart and duration in the further notice message.
Example:
First message with a dtStart1 a no duration (a lime)
Then a second message describing the same interval with a dtStart2 and a duration value:
- Should dtStart1 = dtStart2 and the duration equal to the actual duration the requester wants or wanted (maybe dtStart1 is in the past and the interval is already started, maybe it is in the past and the interval is not yet started).
- Could dtStart2 be arbitray and duration be processed according to dtStart2, or to the timestamp of the 2nd message. Maybe some other options are possible.
This second option would allow someone to send a furher notice with a duration of 0 meaning "stop now".
> WS-Calendar should be able to express an open ended period, i.e. start time, but no end time
> --------------------------------------------------------------------------------------------
>
> Key: WSCALENDAR-124
> URL: http://tools.oasis-open.org/issues/browse/WSCALENDAR-124
> Project: OASIS Web Services Calendar (WS-Calendar) TC
> Issue Type: Improvement
> Components: spec
> Affects Versions: cd01, pr01
> Reporter: Toby Considine
> Assignee: Bruce Bartell
> Fix For: wd15
>
>
> The vEvent type has dtEnd as 1...*, which would be mandatory. What is the end date to be used for the state event?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]