OASIS Web Services Calendar (WS-Calendar) TC
OASIS WS-Calendar TC News Story
Additional description of the WS-Calendar TC is found in the Cover Pages news story: "OASIS Web Services Calendar (WS-Calendar) TC to Create Common Scheduling Standard."
Web Services Calendar (WS-Calendar) TC Charter and Call for Participation
Date: Mon, 25 Jan 2010 14:42:34 -0500 From: Mary McRae [email@example.com] To: firstname.lastname@example.org, email@example.com Cc: firstname.lastname@example.org Subject: Call for Participation: OASIS Web Services Calendar (WS-Calendar) TC Message-ID: 0F508E93-AD8D-4D69-845C-696F4ACCDFC9@oasis-open.org
A new OASIS technical committee is being formed. The OASIS Web Services Calendar (WS-Calendar) Technical Committee has been proposed by the members of OASIS listed below. The TC name, statement of purpose, scope, list of deliverables,
IPR Mode, audience, and language specified in the proposal will constitute the TC's official charter. Submissions of technology for consideration by the TC, and the beginning of technical discussions, may occur no sooner than the TC's first meeting (26-February-2010).
The eligibility requirements for becoming a participant in the TC at the first meeting are:
- you must be an employee of an OASIS member organization or an individual member of OASIS
- you must join the WS-Calendar Technical Committee, which OASIS members may do by using the "Join
ThisTC" button on the TC's home page at [c].
To be considered a voting member at the first meeting, you must:
- join the Technical Committee at least 7 days prior to the first meeting
attend the first meeting of the TC, at the time and date fixed below (26-February-2010 at 2PM EST)
Of course, participants also may join the TC at a later time. OASIS and the TC
welcomeall interested parties.
Non-OASIS members who wish to participate may contact us about joining OASIS [b]. In addition, the public may access the information resources maintained for each TC: a mailing list archive, a document repository, and a public
commentfacility, which is linked from the TC's public home page at [a].
Please feel free to forward this announcement to any other appropriate lists. OASIS is an open standards organization; we encourage your participation.
Mary P McRae
Director, Standards Development
Technical Committee Administrator
OASIS: Advancing open standards for the information society
Twitter: @fiberartisan #oasisopen
WS-Calendar TC: Contents
- CFP Message
- WS-Calendar TC Charter and Call for Participation
- 1. Normative Charter Information
- 2. Non-Normative Information
- Source: Charter and Call for Participation
OASIS Web Services Calendar (WS-Calendar) Technical Committee
According to the OASIS rules for TC formation: Any group of at least Minimum Membership shall be authorized to begin a TC by submitting to the OASIS TC Administrator, with a copy to those listed in 2(d) and 2(e) below, the following items, written in English and provided in electronic form as plain text. No information other than these items may be included in the proposal. All items must be provided in any subsequent revision of the proposal, and must be submitted in the same manner as the original submission.
The name of the TC, such name not to have been previously used for an OASIS TC and not to include any trademarks or service marks not owned by OASIS. The proposed TC name is subject to TC Administrator approval and may not include any misleading or inappropriate names. The proposed name must specify any acronyms or abbreviations of the name that shall be used to refer to the TC.
OASIS Web Services Calendar (WS-Calendar) Technical Committee
A statement of purpose, including a definition of the problem to be solved.
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 oBIX, BACnet/WS, LON-WS, OPC XML, and a number of proprietary specifications including TAC-WS, Gridlogix EnNet, and MODBUS.NET. 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: Internet Calendaring and Scheduling Core Object Specification (iCalendar). 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 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 specifcation is as a component to be used within other specifications, bringing a common scheduling function to diverse interactions in different domains.
Scope of Work of the WS-Calendar Technical Committee, i.e., the scope of the work of the TC, which must be germane to the mission of OASIS, and which includes a definition of what is and what is not the work of the TC, and how it can be determined when the work of the TC has been completed. The scope may reference a specific contribution of existing work as a starting point, but other contributions may be made by TC Members on or after the first meeting of the TC. Such other contributions shall be considered by the TC Members on an equal basis to improve the original starting point contribution.
The Committee will start work with the canonical XML serialization of the updated iCalendar (IETF RFC 5545), hereafter referred to as iCalendar XML, as developed by the Calendaring and Scheduling Consortium (CalConnect.org). This work will provide the vocabulary for use in this web service component.
The committee will also use as a starting point the forthcoming calendaring web service specifications being developed by
CalConnect. These specifications providethe basic mechanismsfor 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 OASIS 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 schedule- and interval-related components.
A list of deliverables, with projected completion dates
The committee will deliver a standard schema and semantics for schedule and interval information for use in other web services. This specification will be derived from and
compatible withthe existing iCalendar XML specification and offer some or all of the functionality of that specification.
The completed specification should include a standard for referring to instances of iCalendar XML within a larger payload, as well as a means to refer to objects external to the iCalendar XML 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
Geoposition is an optional component of the iCalendar XML 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 reference implementation for building systems and smart grid interactions are anticipated to be complete six months after the initial meeting.
This is an aggressive schedule, in support of the NIST smart grid priority actions [such as PAP04: Develop Common Scheduling Mechanism for Energy Transactions, (http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP04Schedules), and dependent on aggressive results from the other priorities as well.
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
ofensuring consistency and interoperation of any additional Calendar and Schedule-related components.
Specification of the IPR Mode under which the TC will operate
The Committee will operate under the OASIS
Non-Assertion [IPR] Mode. [Detail: see the definition and TC Process Section 10.3, 'Non-Assertion Mode TC Requirements']
The anticipated audience or users of the work
It is anticipated that the WS-Calendar will not appear alone, but will be incorporated into other specifications and standards.
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. See: www.oasis-open.org/committees/obix/).
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.
Schedule and 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.
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).
BPEL [Web Services Business Process Execution Language] 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/).
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/). See Work Request and Work Order Fulfilment, which "addresses the information exchanges between the parties involved in the Facilities Management Work Request and Work Order Fulfilment process."
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
EDXL 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. See: http://www.oasis-emergency.org/committees.
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.
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. See: http://www.oasis-open.org/committees/ws-dd/
The language in which the TC shall conduct business
The language of the committee shall be English.
Non-normative information regarding the startup of the [WS-Calendar] TC
WS-Calendar will be a micro-specification, i.e., WS-Calendar is unlikely to be used by itself. WS-Calendar will instead be incorporated into other specifications and standards as a common component.
Identification of similar or applicable work that is being done in other OASIS TCs or by other organizations, why there is a need for another effort in this area and how this proposed TC will be different, and what level of liaison will be pursued with these other organizations.
The definitive work on schedule and interval is the IETF standards iCalendar RFC2445, iTIP RFC2446, and iMIP RFC2447. Those standards are being updated for extensibility by the Calendar and Scheduling Consortium (www.calconnect.org) as RFC 5546 [Internet Calendaring and Scheduling Core Object Specification (iCalendar)],
an updatediTIP RFC 5546 [iCalendar Transport-Independent Interoperability Protocol (iTIP)], and an updated iMIP specification [candidate RFC 5547, iCalendar Message-Based Interoperability Protocol (iMIP)]. CalConnect plans to contribute a canonical XML serialization of iCalendar to the technical committee.
Standards for Calendaring, or for specifying schedule, and interval include but are not limited to:
iCalendar, also known as RFC 5545 (http://www.ietf.org/rfc/rfc5545.txt). iCalendar describes the base semantics and vocabulary to be delivered. The committee may choose to limit the functionality included to a subset of that offered by iCalendar.
hCalendar is a simple, open, distributed calendaring and events format, based on RFC 2445, (http://microformats.org/wiki/hcalendar) suitable for embedding in HTML or XHTML. There are concerns and incompatibilities surrounding the use of hCalendar. See http://www.sitepoint.com/blogs/2008/06/25/bbc-rejects-hcalendar-microformat-because-of-accessibility-concerns/
HTML 5.0 defines microdata, including a calendar component (http://www.w3.org/TR/html5/microdata.html#vevent). The vevent is a fork off an earlier version of iCalendar. Currently, we anticipate that HTML 5.0 will instead reference the iCalendar XML specification.
Open Building Information Exchange (oBIX) has worked since May 2008 to solve this problem within an OASIS TC. This work is incomplete. See: http://lists.oasis-open.org/archives/obix/
The Open Knowledge Initiative (OKI) has developed an Open Service Interface Definition (OSID) for Scheduling [available from SourceForge]. The Scheduling OSID provides a means of associating Agents with specific activities (ScheduleItems). This OSID provides a way for an application to integrate or use an external calendaring system, such as an existing Enterprise calendar system. See Open Service Interface Definition: Scheduling.
IETF Calendaring Extensions to WebDAV (CalDAV) is a protocol to access server-based schedules and calendars by means of extensions to the WEBDAV protocol. CalDAV is also referred to as RFC 4791. See http://www.ietf.org/rfc/rfc4791.txt and HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV).
Microsoft offers the WS-Exchange functions for calendaring. See: (1) GetUserAvailability Operation, an operation that provides detailed information about the availability of a set of users, rooms, and resources within a specified time window — http://msdn.microsoft.com/en-us/library/aa564001(EXCHG.80).aspx; (2) and CreateItem (Calendar Item), an operation that creates appointments, meetings, and meeting requests — http://msdn.microsoft.com/en-us/library/aa564690(EXCHG.80).aspx. Generally: Exchange Web Services XML Elements.
Google calendar defines an XML API for calendar activity with growing use in devices such as Android phones. Interoperating with this API is incorporated into the mission of CalConnect. (http://code.google.com/apis/calendar/data/2.0/developers_guide_protocol.html#CreatingSingle). As well as these schedule and interval, the iCalendar format includes a Geo-position element, which has been limited to a point. Several of the use cases for WS-Calendar would benefit from geo-location. Some would benefit more from a point, and some from region or polygon. This suggests that an additional source of IP for WS-Calendar would be at [OGC]:
The Open Geospatial Consortium (OGC) offers standards for the interchange of geospatial data. The OGC is the preferred source for micro-specifications of geospatial data by WS-Calendar. (http://www.opengeospatial.org/) The committee would reach out to the Consortium for advice as to which geospatial standards to use.
The date, time, and location of the first meeting, whether it will be held in person or by telephone, and who will sponsor this first meeting. The first meeting of a TC shall occur no less than 30 days after the announcement of its formation in the case of a meeting held exclusively by telephone or other electronic means, and no less than 45 days after the announcement of its formation in the case of a meeting held face-to-face (whether or not a telephone bridge is also available).
The first meeting will be
February 26, 2010at 2PM US Eastern Time. The meeting will be by teleconference sponsored by CalConnect.
ongoingmeeting schedule for the year following the formation of the TC, or until the projected date of the final deliverable, whichever comes first, and who will be expected to sponsor these meetings
We anticipate the committee will meet weekly by teleconference sponsored by CalConnect or other TC members.
[2(d)] The names, electronic mail addresses, and membership affiliations of at least Minimum Membership who support this proposal and are committed to the Charter and projected meeting schedule
- David Thewlis, Dave.Thewlis@calconnect.org, CalConnect
- David Wollman, email@example.com, NIST
- David Holmberg, firstname.lastname@example.org, NIST
- Ron Bernstein, email@example.com, LonMark International
- Jeremy Roberts, firstname.lastname@example.org, LonMark International
- David Burke, email@example.com, TIBCO Software Inc
- Larry Lackey, firstname.lastname@example.org, TIBCO Software Inc
- Derek LaSalle, email@example.com, JP MorganChase
- Marquart Franz, firstname.lastname@example.org, Siemens
- Bob Old, email@example.com, Siemens
- Michel Kohanim, firstname.lastname@example.org, [Universal Devices, Individual]
- William Cox, email@example.com, [Cox Software Architects LLC, Individual]
- Toby Considine, Toby.Considine@unc.edu, University of North Carolina
For each OASIS Organizational Member listed in 2(d) Supporters (above), the name, electronic mail address, membership affiliation, and statement of support for the proposed Charter from the Primary Representative
CalConnect: David Thewlis (Dave.Thewlis@calconnect.org): The Calendaring and Scheduling Consortium supports the formation of the OASIS WS-Calendar Technical Committee.
NIST: David Flater (firstname.lastname@example.org): NIST supports the formation of the OASIS WS-Calendar Technical Committee.
LonMark International: Ron Bernstein (email@example.com): We are in full support.
TIBCO Software Inc: David Burke (firstname.lastname@example.org): TIBCO will support the WS-Calendar initiative.
JPMorganChase: Derek LaSalle (email@example.com): As head of Information Architecture at the JPMorgan Investment Bank, I support the formation of the OASIS WS-Calendar Technical Committee.
Siemens AG: Marquardt Franz (firstname.lastname@example.org): As Siemens AG primary OASIS representative, Siemens can be a supporter of OASIS WS-Calendar TC.
University of North Carolina: Toby Considine (Toby.Considine@unc.edu): The University of North Carolina supports the formation of the WS-Calendar Technical Committee as described in the WS-Calendar draft charter.
The name of the Convener who must be an Eligible Person
The name of the Member Section with which the TC intends to affiliate, if any
WS-Calendar will apply to affiliate with the OASIS Blue Member Section.
Optionally, a list of contributions of existing technical work that the proposers anticipate will be made to this TC
The TC will base its work on the IETF iCalendar RFCs. Other contributions are pending.
Optionally, a draft Frequently Asked Questions (FAQ) document regarding the planned scope of the TC, for posting on the TC's website
Optionally, a proposed working title and acronym for the specification(s) to be developed by the TC
Specification: "OASIS Common Scheduling". TC abbreviation "ws-calendar".
The WS-Calendar TC charter/CFP was posted to three OASIS mailing lists:
Prepared by Robin Cover for The XML Cover Pages archive.