• Hide

      See WSCALENDAR-541 and WSCALENDAR-554

      In Internet Draft 05 p5, the syntactic variable "availableprop" is equivalent to PIM AvailableType or AvailabilityType [pending rename per WSCALENDAR-553].

      dtstart is REQUIRED but MUST NOT occur more than once so we require
      dtStart [1..1]; the commenter's change requests dtStart [0..1] which must be rejected.

      On the other hand, including one of dtend/duration is OPTIONAL, so AvailIntervalType.duration should be cardinality [0..1]

      Change cardinality of duration to [0..1] to be more consistent with [Availability].

      Show
      See WSCALENDAR-541 and WSCALENDAR-554 In Internet Draft 05 p5, the syntactic variable "availableprop" is equivalent to PIM AvailableType or AvailabilityType [pending rename per WSCALENDAR-553] . dtstart is REQUIRED but MUST NOT occur more than once so we require dtStart [1..1] ; the commenter's change requests dtStart [0..1] which must be rejected. On the other hand, including one of dtend/duration is OPTIONAL, so AvailIntervalType.duration should be cardinality [0..1] Change cardinality of duration to [0..1] to be more consistent with [Availability] .

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

      (NOTE WTC: RecurrenceType in AvailableType and GluonType (for WD15) addresses much of the comment; AvailableIntervalType:duration [0..1] makes more sense when taken in the context of Vavailability Internet Draft 05)

      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.

            Assignee:
            Michael Douglass (Inactive)
            Reporter:
            William Cox (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: