[OASIS Issue Tracker] (WSCALENDAR-547) Change AvailabilityIntervalType attribute cardinality (see description)

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/WSCALENDAR-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58766#comment-58766 ] 

William Cox commented on WSCALENDAR-547:
----------------------------------------

What does it mean for duration to be optional in a DateTimeType?

Date value - all day.

5545 lacks all day event - floating, TZ not valid. MD comments.



> Change AvailabilityIntervalType attribute cardinality (see description)
> -----------------------------------------------------------------------
>
>                 Key: WSCALENDAR-547
>                 URL: https://issues.oasis-open.org/browse/WSCALENDAR-547
>             Project: OASIS Web Services Calendar (WS-Calendar) TC
>          Issue Type: Sub-task
>          Components: PIM
>    Affects Versions: PIM CS01
>         Environment: Steve Ray comment 20150227
> https://lists.oasis-open.org/archives/ws-calendar-comment/201501/msg00004.html
> Issue 1 of 3. Split for separate discussion.
>            Reporter: William Cox
>            Assignee: Michael Douglass
>             Fix For: PIM WD14
>
>
> From email:
> AvailabilityType.availabilityInterval is of type AvailIntervalType, which contains two mandatory attributes: dtStart and duration. Since this example is talking in general, not about a specific month, I don’t want to name a dtStart. And in this example, I don’t want to give an exact duration, since months are of different lengths. I’m not sure what you allow in DurationType since you have it listed as String. We would like availabilityInterval to be optional, or failing that, have the attributes within AvailIntervalType to be optional, or failing that, at least have AvailIntervalType.dtStart be optional (although I might come up with another use case where I want a start time but not a duration).
> THE FOLLOWING ARE SEPARATE ISSUES
> 2.    VavailabilityType.busy – we don’t have a defined need to use “busy”, “busyUnavailable” and “busyTentative”, so would rather have this attribute as optional.
> 3.    VavailabilityType.timeRange – we would like this attribute to be optional since we are talking in general about an abstract billing interval. We don’t want to bound it to a finite time range.
> So in summary, problem #1 is a real problem for us. Problems #2 and #3 are inconveniences. Hope this example helps.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)