OASIS Web Services Calendar (WS-Calendar) Technical Committee

One of the most fundamental components of negotiating services is agreeing when something should occur, and in auditing when they did occur. Short running services have traditionally been handled as if they were instantaneous, and thereby dodged this requirement through just-in-time requests. Longer running processes may require significant lead times. When multiple long-running services participate in the same business process, it may be more important to negotiate a common completion time than a common start time. Central coordination of such services reduces interoperability as it requires the coordinating agent to know the lead time of each service.

Other processes may have multiple and periodic occurrence. Identical processes may need to be requested on multiple schedules. Other processes must be requested to coincide with or avoid human interactions. An example is a process that occurs on the first Tuesday of every month. Others may need to be completed on schedules that vary by local time zone.

Physical processes are now being coordinated by web services. Building systems and industrial processes are operated using a variety of building- and industrial-automation protocols. Energy use in buildings can be reduced while improving performance if building systems are coordinated with the schedules of the buildings occupants.

An increasing number of specifications envision synchronization of processes through mechanisms including broadcast scheduling. Efforts to build an intelligent power grid (or smart grid) rely on coordinating processes in homes, offices, and industry with projected and actual power availability, including different prices at different times. Two active OASIS Technical Committees require a common means to specify schedule and interval: Energy Interoperation (EITC) and Energy Market Information Exchange (EMIX). Emergency management coordinators wish to inform geographic regions of future events, such as a projected tornado touchdown, using EDXL. These efforts would benefit from a common standard for transmitting schedule and interval.

For human interactions and human scheduling, the well-known iCalendar format is used. Today, there is no equivalent standard for web services. As an increasing number of physical processes are managed by web services, the lack of a similar standard for scheduling and coordination of 34 services becomes critical.

The goal of WS-Calendar is to adapt the existing specifications for calendaring and apply them to develop a standard for how schedule and event information is passed between and within services. The standard should adopt the semantics and vocabulary of iCalendar for application to the completion of web service contracts.

A calendar event without an associated contract is of little use. The anticipated use of the WS-Calendar specification is as a component to be used within other specifications, bringing a common scheduling function to diverse interactions in different domains.

The Committee will start work with the canonical XML serialization (now IETF RFC 6321) of the updated iCalendar (IETF RFC 5545), hereafter referred to as xCal, as developed by the Calendaring and Scheduling Consortium (CalConnect.org). This work will provide the vocabulary for use in this web service component. WS-Calendar will conform to xCal, re-using its semantics and vocabulary for elements addressed by xCal, serving as a web services representation of xCal and adding functionality by extensibility.

The committee will also accept as inputs the CalWS-REST and CalWS-SOAP, the calendaring web service specifications being developed by the CalConnect, using the WS-Calendar base schema, and take in use cases and requirements contributed from those profiles & extensions. This specification will provide the basic mechanism for creating, updating, and deleting calendar events that are common to all calendars and schedules.

The committee expects that use cases and requirements will be contributed by other groups, including the NAESB task forces on smart grid prices and schedules for DR/DER as well as the work done within the oBIX TC to schedule building systems. These use cases will test the completeness and functionality of the specification.

The committee will develop additional Calendar functionality in later work, both in revisions and new specifications. The committee will also accept additional use cases for profile development, centralizing profile development to ensure consistency and interoperation of the additional 61 schedule-and interval-related components.

The committee will deliver a standard schema and semantics for schedule and interval information for use in other web services. The schema and semantics will interoperate with the existing xCal specification and offer some or all of the functionality of that specification. It is the goal of the committee and CalConnect to arrange for cross-contributions of improvements, errata and elaborations to the schema to and from the CalConnect XML working group, and to co-publish and maintain consistent versions of the final schema and CalWS specifications in parallel with CalConnect.

The completed specification should include a standard for referring to instances of xCal within a larger payload, as well as a means to refer to objects external to the xCal instances. A single calendar object may be referenced by multiple contracts. A series of calendar events may reference a single contract.

The committee will deliver a specification for creating, retrieving, updating, and deleting calendar events on a schedule. This specification will be based on the forthcoming calendar web service specifications developed by CalConnect.

Geoposition is an optional component of the xCal structure. Several of the use cases would benefit from geo-location. Some benefit more from a point, and some from a region or polygon. The committee work will include recommendations on how to reference geospatial information, both point and polygon, from within schedule and interval components. Preference will be given to specifications promulgated by the Open Geospatial Consortium (OGC, http://www.opengeospatial.org/).

The committee will encourage members and others to develop reference implementations of the schedule components necessary to support the NAESB and oBIX use cases as described above. These implementations will test the completeness and functionality of the specification. These profiles will be donated to the EMIX, EITC, and oBIX Technical Committees at completion of the initial version of WS-Calendar. The committee may choose to incorporate additional use cases from other sources into its initial work.

Version 1 of the specification and information model for building systems and smart grid interactions was published in September, 2011. Future versions will specify of RESTful and SOAP communications using the standard.

An initial impetus for launching this work was the NIST smart grid priority action plans, (http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP04Schedules). The needs of other Technical Committees supporting other priority action plans were instrumental in the decision to release the initial specification without the communication specifications.

The committee will add additional functionality to later versions of the specification as agreed upon by the committee. The committee will also address additional use cases from additional domains for reference implementation, with a goal of to ensuring consistency and interoperation of any additional Calendar and Schedule-related components.

The Committee will operate under the OASIS Non-Assert mode.

It is anticipated that the WS-Calendar will not appear alone, but will be incorporated into other specifications and standards.

1. oBIX plans to use the scheduling specification for exchange of information with enterprise and external services. There is a natural and easy use case for oBIX that looks like "Conference room scheduled for 17 people at 3:00, tell building systems to establish temperature/humidity/warm up equipment by 3:00 Ventilation adequate for 17 people and continue to do so for the full hour" (www.oasis-open.org/committees/obix/).
2. Collaborative energy presents a number of use cases for coordinating Demand Response (DR), Distributed Energy Resources (DER), and other transactions associated with the power grid. These economic transactions need scheduling both for time of day pricing and for scheduled power generation and use. This work is being done in the Energy Interoperation TC (EITC) (www.oasis-open.org/committees/energyinterop/). Current EITC work plans anticipate incorporating this work.
3. Schedule & interval are critical parts of energy product definition, for both current and forward energy markets. This work is being done in the Energy Market Information Exchange (EMIX) TC (www.oasis-open.org/committees/emix/). Current EMIX work plans anticipate incorporating this work.
4. Emergency management would like to be able to transmit warnings and predictions of upcoming events. A common scheduling component would aid in cross-domain communications. A schedule component has been anticipated for future EDXL communications (http://www.oasis-emergency.org/committees ).
5. BPEL does not currently have any good way to handle the repeating event or several time coordinated events. A specification for scheduling could be incorporated in future versions of BPEL and its offshoot BPEL4People (www.oasis-open.org/committees/bpel4people/).
6. The OSCRE developed specification for the exchange of service work orders would benefit from the addition of a common scheduling and coordination function, including one which supports repetitive scheduling. Such a specification could also be used to specify windows during which the performance of work would minimally inconvenience building occupants. Alignment of building performance and tenant activity may become part of new business interactions such as Green Leases. Further work in this area would be developed by PISCES (http://web.pisces.co.uk/).
7. Electronic medical records and shared medical services are receiving growing attention. Many medical services are provided by many service providers working, occasionally, in concert. A common calendaring function would aid in coordinating these services across organizational boundaries to the patients benefit.
8. HAVE (Hospital Availability Exchange) could be improved if equipment availability and maintenance schedules could easily be shared in advance. HAVE is part of the OASIS Emergency Interoperability suite section (http://www.oasis-emergency.org/committees).
9. The Green Grid (www.TheGreenGrid.org) is concerned with the interactions between data centers and the critical resources that support them. These resources symmetrically share availability and planned maintenance information with the data center.
10. The OASIS Technical Committee for WS-Device Discovery and Device Profiles (WS-DD) includes members with an interest in devices of concern to the oBIX, Demand-Response, and Green Grid. A schedule and interval specification could add an availability component to the Device Profile.
11. There is initial work that uses the semantic elements from WS-Calendar to create static assertions about operating environments and service level agreements.

The language of the committee shall be English.