[OASIS Issue Tracker] (WSCALENDAR-549) Request that VavailabilityType.timeRange attribute be optional (rejected)

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

     [ https://issues.oasis-open.org/browse/WSCALENDAR-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

William Cox updated WSCALENDAR-549:
-----------------------------------

    Resolution: 
Accept the proposal. Re-review after next draft of Standards Track Vavailability RFC.

Examine PIM for consistency in allowing optional attributes where all content is optional.

Re-processing.

> Request that VavailabilityType.timeRange attribute  be optional (rejected)
> --------------------------------------------------------------------------
>
>                 Key: WSCALENDAR-549
>                 URL: https://issues.oasis-open.org/browse/WSCALENDAR-549
>             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
> Steve Ray followup comment 20150305
> https://lists.oasis-open.org/archives/ws-calendar-comment/201503/msg00000.html
>            Reporter: William Cox
>            Assignee: Michael Douglass
>             Fix For: PIM WD14
>
>
> Issue 3 of 3. Split for separate discussion. See WSCALENDAR-547 for full issue and references.
> 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. 
> Additional Comment:
> On behalf of the ASHRAE SPC201 committee, we would like to request Vavailability.timeRange be an optional attribute. While we recognize that its datatype AvailabilityTimeRangeType contains all optional attributes, we would like the option of not having to carry around an empty structure if the user does not choose to limit the range of time.



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