CP RSS Channel
About Our Sponsors
Articles & Papers
Technology and Society
|OASIS Web Services Calendar (WS-Calendar) TC to Create Common Scheduling Standard.|
Update 2010-10-24: On September 24, 2010, OASIS announced a 60-day public review for the Committee Draft 01 version of WS-Calendar, including the core WS-Calendar Version 1.0 specification (with XML schema files, RDDL, EAP) and the companion White Paper Conceptual Overview of WS-Calendar: Understanding Inheritance Using the Semantic Elements of Web Services.
Update 2010-05-19: On May 19, 2010, members of the OASIS Web Services Calendar (WS-Calendar) Technical Committee released a working draft for informal public comments: WS-Calendar Version 1.0, Working Draft 06. The WS-Calendar specification "describes a common set of message components for specifying schedules and intervals to coordinate activities between services. Web services definitions, service definitions consistent with the OASIS SOA Reference Model, and XML vocabularies for the interoperable and standard exchange of: (a) Schedules, including sequences of schedules; (b) Intervals, including sequences of intervals. The definition of the service performed to meet a schedule or interval depends on the market context in which it exists. It is not in scope for this TC to define those markets or services..." See the TC's document repository for updates, and the local ZIP archive containing the PDF, Word (.doc) and HTML formats (file listing).
In January 2010, OASIS announced the formation of a new Web Services Calendar (WS-Calendar) Technical Committee, chartered to adapt existing calendaring and scheduling specifications toward development of a "Common Scheduling" standard to define how schedule and event information is passed between and within services. The committee will deliver a specification for creating, retrieving, updating, and deleting calendar events on a schedule. This includes a standard schema and semantics for schedule and interval information for use in other web services.
While the initial motivation for WS-Calendar work came from the smart grid domain (schedule and interval for energy transmission and payments), the TC proposers feel that a common scheduling specification for web services would be applicable to a wide range of industry requirements where transactions and business processes depend critically upon scheduling. Time synchronization, schedule alignment, and performance alignment are nearly universal business process concerns, as described in the WS-Calendar TC Charter:
"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..."
The WS-Calendar TC will start work with the canonical XML serialization of the updated iCalendar specification (IETF RFC 5545, Internet Calendaring and Scheduling Core Object Specification — iCalendar), currently published as a IETF Standards Track Internet Draft: iCalendar XML Representation [xCal]. CalConnect plans to contribute this canonical XML serialization iCalendar document to the WS-Calendar TC. The iCalendar XML draft is being developed by the Calendaring and Scheduling Consortium (CalConnect) XML Technical Committee (TC-XML) and reviewed in IETF. The completed OASIS 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, and a series of calendar events may reference a single contract.
The WS-Calendar TC Charter notes that definitive work on schedule and interval is found in the IETF standards iCalendar, iTIP, and iMIP, recently updated within the IETF Calendaring and Scheduling Standards Simplification (CALSIFY) Working Group. These now include:
Several previous technical activities have focused upon development of markup-language formalisms to represent iCalendar information, including: (1) RDF Calendar: An Application of the Resource Description Framework to iCalendar Data; (2) iCalendar in XML Format (xCal-Basic); (3) Guideline for Use of XML with iCalendar Elements; (4) iCalendar DTD Document (xCal); (5) The iCalendar DTD Document; (6) The iCalendar XML DTD. Principals in the iCalendar XML Representation [xCal] work feel that critical mass may now have been reached such that developers of calendaring and scheduling applications will now recognize the benefits of standardized XML format and support adoption of the CalConnect/IETF specification.
The ongoing effort toward standardization of an iCalendar XML Representation [xCal] takes cognizance of the vCard XML Schema specification being developed within the IETF vCard and CardDAV (VCARDDAV) Working Group. Participants in the CalConnect and IETF working parties sense that benefits will come from alignment of the two XML representation formats, particularly with respect to iCalendar extensibility mechanisms.
The proposed OASIS "Common Scheduling" standard will adopt the semantics and vocabulary of iCalendar for application to the completion of web service contracts. It is anticipated that the WS-Calendar specification will not appear alone, but will be incorporated into other specifications and standards. That is: it is designed to serve as a component within other specifications, bringing a common scheduling function to diverse interactions in different domains.
Motivation for formation of the new WS-Calendar Technical Committee comes from a recognition that "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 TCs now require a common means to specify schedule and interval. Emergency management coordinators wish to inform geographic regions of future events, such as a projected tornado touchdown... these efforts would benefit from a common standard for transmitting schedule and interval."
As described in the Charter, the WS-Calendar TC will encourage members and others to develop reference implementations of the schedule components necessary to support the NAESB and oBIX use cases. 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. The committee work will include recommendations on how to reference geospatial information, both point and polygon, from within schedule and interval components.
Representatives from CalConnect, NIST, LonMark International, TIBCO Software, JP MorganChase, Siemens, Universal Devices, Cox Software Architects, and University of North Carolina contributed the WS-Calendar charter proposal, and invite participation from all relevant industry experts and stakeholders. The initial WS-Calendar TC meeting will be held as a teleconference on February 26, 2010. David Thewlis, Executive Director of the Calendaring and Scheduling Consortium (CalConnect), serves as TC Convenor. CalConnect now "has a Reciprocal Membership relationship with OASIS, in particular to further work on XML representation of ICalendar data and web services support for calendaring and scheduling information."
Note: This hyperlinked version of the Charter/CFP adds a few data points and URI references to enhance usability; it also corrects minor errors. See references for the original posting.
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
Statement of Purpose
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 provide the basic mechanisms 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 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 with the 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 CalConnect.
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 of ensuring consistency and interoperation of any additional Calendar and Schedule-related components.
OASIS IPR Mode
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 patient's benefit.
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 updated iTIP 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, 2010 at 2PM US Eastern Time. The meeting will be by teleconference sponsored by CalConnect.
The projected ongoing meeting 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, firstname.lastname@example.org, NIST
- David Holmberg, email@example.com, NIST
- Ron Bernstein, firstname.lastname@example.org, LonMark International
- Jeremy Roberts, email@example.com, LonMark International
- David Burke, firstname.lastname@example.org, TIBCO Software Inc
- Larry Lackey, email@example.com, TIBCO Software Inc
- Derek LaSalle, firstname.lastname@example.org, JP MorganChase
- Marquart Franz, email@example.com, Siemens
- Bob Old, firstname.lastname@example.org, Siemens
- Michel Kohanim, email@example.com, [Universal Devices, Individual]
- William Cox, firstname.lastname@example.org, [Cox Software Architects LLC, Individual]
- Toby Considine, Toby.Considine@unc.edu, University of North Carolina
Support from Primary Representatives
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 (email@example.com): NIST supports the formation of the OASIS WS-Calendar Technical Committee.
LonMark International: Ron Bernstein (firstname.lastname@example.org): We are in full support.
TIBCO Software Inc: David Burke (email@example.com): TIBCO will support the WS-Calendar initiative.
JPMorganChase: Derek LaSalle (firstname.lastname@example.org): 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 (email@example.com): 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
OASIS Member Section
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:
Update 2011-08-08: xCal: The XML Format for
iCalendar was released as an IETF Proposed Standard Protocol (RFC 6321), as announced 2011-08-08 by the IETF
through the RFC Editor Team. Published August 2011 in the IETF Standards Track as 'Request for Comments #6321', with ISSN
2070-1721. Edited by Cyrus Daboo (Apple Inc),
Mike Douglass (Rensselaer Polytechnic Institute), and Steven Lees (Microsoft Corporation). 54
Note 2010-03-10: The IETF Internet Draft bearing the title iCalendar XML Representation (e.g., 'draft-daboo-et-al-icalendar-in-xml-01', published November 25, 2009) was assigned a new title xCal: The XML Format for iCalendar as of March 8, 2010 with the publication of draft-daboo-et-al-icalendar-in-xml-02. Therefore, most references to "iCalendar XML" or "iCalendar XML Representation" in this document may be considered equivalent to the successor document with the title xCal: The XML Format for iCalendar.
The OASIS WS-Calendar Technical Committee will "start work with the canonical XML serialization of the updated iCalendar referred to as iCalendar XML, being developed by the Calendaring and Scheduling Consortium (CalConnect). This work will provide the vocabulary for use in this web service component..."
The CalConnect XML Technical Committee (TC-XML) was established in February 2008 to "develop the following specifications: (1) A specification for a two-way reference mapping of iCalendar to XML; (2) A core abstract calendaring API, and a concrete web services binding for that API. The initial design goal for this set of specifications is based on the NIST Smart Grid requirements for a web services calendaring and scheduling API. The group's goals for WS-Calendar work include: [i] delivering a a WS-Calendar specification that meets the needs of the NIST Smart Grid effort, and [ii] delivering a core abstract calendaring API that will serve as a base specification for future work, and support other protocol bindings in the future..."
The CalConnect XML Technical Committee goals for XML iCalendar Work are:
- Define a mapping of iCalendar so that the same iCalendar input always produces the same XML result
- Define a mapping of XML to iCalendar so that the same XML input always products the same iCalendar result
- Define a mapping so that both XML and iCalendar input can be round-tripped whenever possible without losing or changing content
- Define a mapping which results in a destination representation which is just as concise as the source representation
- Propose a MIME media type that can be used to transport the XML version of the iCalendar data
- Submit the resulting specification to the IETF as an RFC
- Inform and be informed by the current IETF work on vCard
As of February 06, 2010, two drafts of the iCalendar XML Representation specification had been published through the IETF process. See the Note on xCal for a name change to xCal: The XML Format for iCalendar when Version -02 (draft-daboo-et-al-icalendar-in-xml-02) was published.
iCalendar XML Representation. By Cyrus Daboo (Apple Inc), Mike Douglass (Rensselaer Polytechnic Institute), and Steven Lees (Microsoft Corporation). IETF Network Working Group, Standards Track Internet Draft. Version -01 'draft-daboo-et-al-icalendar-in-xml-01' published November 25, 2009, expires May 29, 2010. 43 pages. Updated in Version -01 as Announced 2009-11-25; see the I-D Tracker
Abstract: "This specification defines a format for representing iCalendar data in XML." Introduction: "The iCalendar data format (RFC 5545) is a widely deployed interchange format for calendaring and scheduling data. While many applications and services consume and generate calendar data, iCalendar is a specialized format that requires its own parser/generator. In contrast, XML-based formats are widely used for interoperability between applications, and the many tools that generate, parse, and manipulate XML make it easier to work with than iCalendar. The purpose of this specification is to define an XML format that allows iCalendar data to be converted to XML, and then back to iCalendar, without losing any semantic meaning in the data. Anyone creating XML calendar data according to this specification will know that their data can be converted to a valid iCalendar representation as well. Two key design considerations are: (1) Round-tripping (converting an iCalendar instance to XML and back) will give the same result as the starting point. (2) Preserve the semantics of the iCalendar data. While a simple consumer can easily browse the calendar data in XML, a full understanding of iCalendar is still required in order to modify and/or fully comprehend the calendar data."
xCal: The XML Format for iCalendar. By Cyrus Daboo (Apple Inc), Mike Douglass (Rensselaer Polytechnic Institute), and Steven Lees (Microsoft Corporation). IETF Network Working Group, Standards Track Internet Draft. Version -02 'draft-daboo-et-al-icalendar-in-xml-02' published March 8, 2010, expires September 09, 2010. 42 pages. An update to iCalendar XML Representation, as announced March 08, 2010, with notice in XML Daily News. Update to Version -05 on July 13, 2010.
This IETF Internet Draft previously published under the title iCalendar XML Representation was revised and issued under the new title xCal: The XML Format for iCalendar. This Version -02 adds Section 5 ('Handling Link Elements in XML and iCal'), which recommends a preferred format for links in xCal documents, specifies an iCalendar extension for including links in iCalendar documents, and describes how to convert between the two formats...
Handling Link Elements in XML and iCal: Both Atom (RFC 4287) and HTML use a link element to reference external information which is related in some way to the referencing document. iCalendar (RFC 5545) does not have such a mechanism. There are several common use cases where it would be useful for a calendar item to link to external structured data. For instance, it would be useful for an event item to denote the location of the event by referencing a vCard. Similarly, there may be a primary contact person for the event, and that person's vCard should be linked from the event as well.
It is recommended therefore that calendar data in the xCal format use the Atom link element, as specified in RFC 5545 section 4.2.7, for linking to external related resources. The Relation Name 'location' designates a location for the referencing item. Typically the location will be in the form of a vCard, but it could be some other kind of document containing location information... A LINK extension property for iCalendar is used to reference external documents related to this calendar item. The property can appear on any iCalendar component, and the value of this property is a URI which references an external resource related to the component. Since the LINK parameter is specified in terms of the link element defined by RFC 5545, converting between the two is straightforward. When converting from iCalendar to xCal, simply take any parameters present and assign their values to the corresponding attribute on the link element. Any unknown extensions either in the iCalendar or xCal format MAY be ignored when converting to the other format..."
The current (2010) CalConnect/IETF initiative to produce an iCalendar XML Representation follows in a sequence of earlier activities focused upon markup-language formalisms to represent iCalendar information.
W3C RDF Calendar Workspace, with mail archives for 'firstname.lastname@example.org'. A W3C Interest Group Note RDF Calendar: An Application of the Resource Description Framework to iCalendar Data (eds. Dan Connolly and Libby Miller) was published on 29-September-2005 as part of the W3C RDF calendar task force in the Semantic Web Interest Group and Semantic Web Activity. This report "discusses an effort to apply the Resource Description Framework (RDF) to iCalendar data in order to integrate calendar data with other Semantic Web data such as social networking data, syndicated content, and multimedia meta-data. We demonstrate the effectiveness of a test-driven approach to vocabulary development and we discuss a number of social as well as technical issues."
The W3C RDF Calendar Workspace and ESW Wiki report on the development of several iCalendar schemas in RDF/XML, RDF/n3, etc., and conversion tools. For other details, see the reference document and links from the ESW Wiki: Calendar User Agents.
iCalendar in XML Format (xCal-Basic). Edited by Doug Royer (IntelliCal LLC). IETF Network Working Group, Internet Draft. Version -03: 'draft-royer-calsch-xcal-03', published October 22, 2005. 23 pages.
"The mailing list for discussion of this memo is 'xCal@INET-Consulting.com'... This is a re-release of an expired draft with updates and a much more simplified approach. This approach uses an exact 1-to-1 mapping between iCalendar and XML objects... xCal is a representation of iCalendar objects in XML. xCal is not an alternative or next generation of iCalendar. This memo defines how to use XML to represent iCalendar objects in XML. These XML object can be embedded into other XML documents using the XML syntax here. xCal does represent iCalendar componnts, properties, and parameters as defined in iCalendar. As iCalendar evolves the one to one mapping of iCalendar objects into xCal will continue to work as this memo describes the mapping of iCalendar objects.. Within this memo the term 'xCal' will mean the XML namespace usage as described in this memo. This format was selected to ease its translation back to the iCalendar format using an XSLT transform. See project iCalendar on SourceForge.com. Note: that RFC 2445 iCAL is the definitive reference for the definition of iCalendar semantics. This memo only provides an alternative, XML representation for the standard syntax defined in RFC 2445. This memo does not introduce any semantics not already defined by RFC 2445..."
Guideline for Use of XML with iCalendar Elements. Edited by Tim Hare. IETF Network Working Group, Internet Draft. Version -03 'draft-hare-xcalendar-03' published May 16, 2005, expires November 17, 2005. 48 pages. See the I-D Tracker.
"This memo defines a guideline for using XML to represent calendaring information that corresponds to the iCalendar, Internet Calendaring and Scheduling Core Object Specification defined by RFC 2445 and the protocols defined by RFC 2446, RFC 2447 and 'Calendar Access Protocol'. This memo applies to all RFC 2445 extensions and modifications... This memo defines how XML can be used to represent iCalendar objects,and how iCalendar namespaces can be used with other XML documents. An example DTD is provided although use of a DTD is not required. This memo does not try to enforce any specific one-to-one mapping between XML objects and iCalendar objects, but instead attempts to document the method whereby XML developers can provide interoperability with iCalendar... This memo requires that conforming documents include a reference to an [XSL] stylesheet for transforming the document into standard iCalendar format. How the transformation is done is left to the implementor..."
iCalendar DTD Document (xCal). Edited by Frank Dawson (Nokia Corporation), Surendra K. Reddy (Oracle Corporation), Doug Royer (INET-Consulting LLC), and Eric R. Plamondon (Oracle Corporation). IETF Network Working Group, Internet Draft. Version -02 'draft-ietf-calsch-many-xcal-02' published July 25, 2002, expires January 23, 2003. 53 pages.
"This memo defines a XML Document Type Definition (DTD) that corresponds to the iCalendar, Internet Calendaring and Scheduling Core Object Specification defined by RFC 2445. This DTD provides equivalent functionality to the standard format defined by RFC 2445. Documents structured in accordance with this DTD may also be known as "XML iCalendar" documents or "xCal"... RFC 2445 is the definitive reference for the definition of iCalendar semantics. This memo only provides an alternative, XML representation for the standard syntax defined in RFC 2445. This memo does not introduce any semantics not already defined by RFC 2445. An attempt has been made to leverage the standard features of the XML syntax in order to represent the component iCalendar semantics. For example, strong data typing is specified using the XML notation declaration. The element type attributes are used to represent many of the calendar properties that provide a "global attribute" capability in an iCalendar object. Binary content in the ATTACH component property may either be specified through an external entity reference to a non-XML binary content or may be included in the XML document's content information, after first being encoding using the BASE64 scheme of RFC 2146..."
The iCalendar DTD Document. Edited by Frank Dawson (Lotus Development Corporation), Surendra K. Reddy (Oracle Corporation), and Doug Royer (Sun Microsystems). IETF Network Working Group, Internet Draft. Version -01 published June 10, 1999, expires December 10, 1999. 40 pages.
"This memo defines a XML Document Type Definition (DTD) that corresponds to the iCalendar, Internet Calendaring and Scheduling Core Object Specification defined by RFC 2445. This DTD provides equivalent functionality to the standard format defined by RFC 2445. Documents structured in accordance with this DTD may also be known as 'XML iCalendar' documents or 'ICALXML'... This memo defines an alternative, XML representation for the standard iCalendar format defined in RFC 2445; this alternative representation provides the same semantics as that defined in the standard format. The standard format can be converted to and from this XML format without loss of any calendaring information. When the XML representation was defined, every attempt was made to use existing component, property and parameter naming conventions. This greatly facilitates transformations between the two representations... It is expected that the DTD defined in this memo will not normally be included with iCalendar XML documents that are distributed. Instead, the DTD will be referenced in the document type declaration in the document entity. Such iCalendar XML documents will be well-formed and valid, as defined in XML. In addition, other iCalendar XML documents will be specified that do not include the XML prolog. Such iCalendar XML documents will be well-formed but not valid..."
The iCalendar XML DTD. Edited by Frank Dawson (Lotus Development Corporation). IETF Network Working Group, Internet Draft. Version -01: 'draft-dawson-ical-xml-dtd-01.txt', December 4, 1998. 22 pages.
"This memo defines a XML Document Type Definition (DTD) that corresponds to the iCalendar, calendaring and scheduling core object format defined by RFC 2445. This DTD provides equivalent functionality to the standard format defined by RFC 2445. Documents structured in accordance with this DTD may also be know as 'XML iCalendar' documents... This XML DTD is in no way intended to create a separate definition for the vCard schema. The sole purpose for this memo is to define an alternative XML encoding for the format defined by RFC 2445. The vCard DTD does not introduce any capability not expressible in the format defined by RFC 2445. However, an attempt has been made to leverage the capabilities of the XML syntax to better articulate the original intent of the iCalendar authors. For example, the notation attribute is used to declare the strong data typing intended for each of the properties in an iCalendar object. It is the responsibility of the XML application supporting this DTD to make sure that the content information is formatted consistently with the notation declared for each element. The iCalendar DTD promotes a number of iCalendar properties into attributes on the 'iCal' element. This has been done to express these properties as 'global attributes' for the iCalendar object, as a whole. For example, the 'CALSCALE', 'METHOD', 'VERSION', and 'PRODID' properties have been mapped into attributes on the iCalendar object. Binary content in the 'ATTACH' property may either be specified through an external entity reference to the non-XML binary content or may be included in the content after first encoding the binary information using the BASE64 encoding of RFC 2146..."
Internet Calendaring and Scheduling Core Object Specification (iCalendar). Edited by Bernard Desruisseaux (Oracle Corporation). Network Working Group, Standards Track Request for Comments #5545. Proposed Standard. With Errata. Obsoletes RFC 2445 (November 1998). 168 pages. Abstract: "This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol." Announced 2009-09-24. See the I-D Tracker.
Details: "The use of calendaring and scheduling has grown considerably in the last decade. Enterprise and inter-enterprise business has become dependent on rapid scheduling of events and actions using this information technology. This memo is intended to progress the level of interoperability possible between dissimilar calendaring and scheduling applications. This memo defines a MIME content type for exchanging electronic calendaring and scheduling information. The Internet Calendaring and Scheduling Core Object Specification, or iCalendar, allows for the capture and exchange of information normally stored within a calendaring and scheduling application; such as a Personal Information Manager (PIM) or a Group-Scheduling product.
The iCalendar format is suitable as an exchange format between applications or systems. The format is defined in terms of a MIME content type. This will enable the object to be exchanged using several transports, including but not limited to SMTP, HTTP, a file system, desktop interactive protocols such as the use of a memory- based clipboard or drag/drop interactions, point-to-point asynchronous communication, wired-network transport, or some form of unwired transport such as infrared.
This I-D also provides for the definition of iCalendar object methods that will map this content type to a set of messages for supporting calendaring and scheduling operations such as requesting, replying to, modifying, and canceling meetings or appointments, to-dos, and journal entries. The iCalendar object methods can be used to define other calendaring and scheduling operations such as requesting for and replying with free/busy time data. Such a scheduling protocol is defined in the iCalendar Transport-independent Interoperability Protocol (iTIP)... The memo also includes a formal grammar for the content type based on the Internet ABNF defined in RFC 5234. This ABNF is required for the implementation of parsers and to serve as the definitive reference when ambiguities or questions arise in interpreting the descriptive prose definition of the memo..."
iCalendar Transport-Independent Interoperability Protocol (iTIP). Edited by Cyrus Daboo ( Apple Inc). Network Working Group, Standards Track Request for Comments #5546. Proposed Standard. December 23, 2009. Obsoletes RFC 2446 (November 1998), "iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries." Announced 2010-01-14, and see publication announced belatedly February 23, 2010 for the December 2009 publication.
Abstract: "This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems. The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling."
iCalendar Message-Based Interoperability Protocol (iMIP). Edited by Alexey Melnikov (Isode Ltd). IETF Network Working Group, Standards Track Internet Draft. Version -08 'draft-ietf-calsify-rfc2447bis-08.txt' dated January 30, 2010, expires June 30, 2010. 22 pages. Will obsolete IETF RFC 2447. Announced February 01, 2010; see diff with version -07. Note from Eliot Lear on 2009-12-01: document is at IETF CALSIFY Working Group Last Call. Updated in Version -10, July 27, 2010 (diff).
Abstract: "This document, iCalendar Message-Based Interoperability Protocol (iMIP), specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCAL) are wrapped using constructs from RFC 5322, RFC 2045, RFC 2046, RFC 2047 and RFC 2049, and then transported over SMTP. This document is a product of the Calendaring and Scheduling Standards Simplification (calsify) working group. More information about the IETF CALSIFY working group activities can be found on the IETF web site.
Internet Calendar Scheduling Protocol (iSchedule). By Cyrus Daboo ( Apple Inc) and Bernard Desruisseaux (Oracle Corporation). IETF Network Working Group, Standards Track Internet Draft. Version -00: 'draft-desruisseaux-ischedule-00': November 15, 2009, expires May 19, 2010. 34 pages. Updated in Version -01, March 8, 2010 (diff).
Abstract: "This document defines the Internet Calendar Scheduling Protocol (iSchedule), which is a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to the Hypertext Transfer Protocol (HTTP) to enable interoperability between calendaring and scheduling systems over the Internet." Announced 2009-11-16; see Tracker, and -00 Tracker Entry
CalDAV Scheduling Extensions to WebDAV. IETF Network Working Group, Standards Track Internet Draft. Edited by Cyrus Daboo (Apple Inc) and Bernard Desruisseaux (Oracle Corporation). Version -08 'draft-desruisseaux-caldav-sched-08' published August 20, 2009, expires February 21, 2010. 95 pages. If approved, this specification will update RFC 4791. See the Tracker and caldav Discussion List Archive.
"This document defines extensions to the CalDAV 'calendar-access' feature to specify a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the 'calendar-auto-schedule' feature of CalDAV. The document specifies extensions to the CalDAV "calendar-access" (RFC 4791) feature to enable scheduling of iCalendar-based calendar components between Calendar Users. This extension leverages the scheduling methods defined in the iCalendar Transport-independent Interoperability Protocol (iTIP) to permit Calendar Users to perform scheduling transactions such as schedule, reschedule, respond to scheduling request or cancel scheduled calendar components, as well as search for busy time information...
Approach: iTIP outlines a model where Calendar Users exchange scheduling messages with one another. Often times, Calendar User Agents are made responsible for generating and sending scheduling messages as well as processing incoming scheduling messages. This approach yields a number of problems, including: (1) For most updates to a scheduled calendar component, Calendar User Agents need to address a separate scheduling messages to the Organizer or the Attendees. (2) The handling of incoming scheduling messages and the updates to calendars impacted by those messages only occurs when Calendar User Agents are active. (3) Due to the update latency, it is possible for calendars of different Calendar Users to reflect different, inaccurate states. This specification [therefore] uses an alternative approach where the server is made responsible for sending scheduling messages and processing incoming scheduling messages. This approach frees the Calendar User Agents from the submission and processing of scheduling messages and ensures better consistency of calendar data across users' calendars. The operation of creating, modifying or deleting a scheduled calendar component in a calendar is enough to trigger the server to deliver the necessary scheduling messages to the appropriate Calendar Users..."
Calendaring Extensions to WebDAV (CalDAV). Edited by Cyrus Daboo (Apple Inc), Bernard Desruisseaux (Oracle Corporation), and Lisa Dusseault (CommerceNet). IETF Standards Track Request for Comments #4791. Proposed Standard. March 2007. 107 pages. "This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the 'calendar-access' feature of CalDAV...
The concept of using HTTP (RFC 2616) and WebDAV (RFC 2518) as a basis for a calendar access protocol is by no means a new concept: it was discussed in the IETF CALSCH working group as early as 1997 or 1998. Several companies have implemented calendar access protocols using HTTP to upload and download iCalendar (RFC 2445) objects, and using WebDAV to get listings of resources. However, those implementations do not interoperate because there are many small and big decisions to be made in how to model calendaring data as WebDAV resources, as well as how to implement required features that aren't already part of WebDAV. This document proposes a way to model calendar data in WebDAV, with additional features to make an interoperable calendar access protocol...
When XML element types in the namespaces DAV: and urn:ietf:params:xml:ns:caldav are referenced in this document outside of the context of an XML fragment, the string DAV: and CALDAV: will be prefixed to the element type names, respectively. Definitions of XML elements in this document use XML element type declarations (as found in XML Document Type Declarations)... The namespace urn:ietf:params:xml:ns:caldav is reserved for the XML elements defined in this specification, its revisions, and related CalDAV specifications. XML elements defined by individual implementations MUST NOT use the urn:ietf:params:xml:ns:caldav namespace, and instead should use a namespace that they control. The XML declarations used in this document do not include namespace information. Thus, implementers must not use these declarations as the only way to create valid CalDAV properties or to validate CalDAV XML element types. Some of the declarations refer to XML elements defined by WebDAV, which use the DAV: namespace. Wherever such XML elements appear, they are explicitly prefixed with "DAV:" to avoid confusion. Also note that some CalDAV XML element names are identical to WebDAV XML element names, though their namespace differs. Care must be taken not to confuse the two sets of names. Processing of XML by CalDAV clients and servers MUST follow the rules described in RFC 2518; in particular, Section 14, and Appendix 3 of that specification...
"vCalendar: The Electronic Calendaring and Scheduling Exchange Format Version 1.0. September 18, 1996. A versit Consortium Specification. Copyright © International Business Machines Corp., Lucent Technologies, Inc., and Siemens. See the specification Overview. "This specification defines a format for an electronic calendaring and scheduling (vCalendar) format. The vCalendar format allows for the capture of information normally stored within a calendaring and scheduling application; such as a Personal Information Manager or a Group Scheduling product. The format is suitable as an interchange format between applications or systems. The format is defined independent of the particular method used to transport it. The transport for this exchange might be a file system, point-to-point asynchronous communication, wired-network transport, or some form of unwired transport. A vCalendar is a data stream consisting of one or more vCalendar objects. The individual vCalendar definitions can be identified and parsed within the data stream. The vCalendar data stream may exist as a persistent form in a file system, document management system, network connection between two network endpoints, or in any other digital transport that has an abstraction of a stream of bytes. Conceptually, a vCalendar Writer creates vCalendar data streams and a vCalendar Reader interprets vCalendar data streams. The vCalendar Reader and Writer may be implemented as a single application or as separate applications. It is not the intent of this specification to define the implementation of these processes beyond some fundamental capabilities related to the format of the vCalendar data stream and a common set of conformance requirements. This specification provides for a clear-text encoding. The specification also includes a formal grammar for the clear-text encoding to aid in the implementation of parsers and to serve as the definitive reference when ambiguities or questions arise in interpreting the descriptive prose definition of the specification. The clear-text encoding of this specification can be used in environments which are constrained to 7-bit transfer encodings, short line lengths, and low bandwidth. In addition, the encoding is simple in order to facilitate the implementation of reader and writer applications on small platforms, such as Personal Digital Assistants (PDA), cellular telephones, or alphanumeric pagers..."
A chartered goal of the CalConnect XML iCalendar Work is to "inform and be informed by the current IETF work on vCard." In particular, language designers have been attentive to alignment of the iCalendar XML Representation specification with vCard XML Schema in terms of XML encoding constructs. Several IETF Internet Drafts have been published for a vCard XML Schema specification which defines an XML representation for vCard.
vCard XML: Alignment of icalendar-in-xml and vCard. Posted by Cyrus Daboo to the IETF VCARDDAV Discussion List on February 26, 2010. "Here is a summary of what the CalConnect folks came up with with icalendar-in-xml as applied to vCard. I think the same principals should be applied to what we do in vcard: (1) Full round tripping of vCard data to/from XML. Semantic equivalence is required, but syntactic equivalence is not required (e.g., lowercase vCard property -> XML -> uppercase vCard). (2) All syntactic elements on the vCard side (components, properties, parameters) must be mapped to XML elements in the urn:ietf:params:xml:ns:vcard-4.0 namespace. This applies to X- properties as well — only exception is the XML: property described below. 3) All XML elements in the urn:ietf:params:xml:ns:vcard-4.0 namespace must be mapped to their vCard equivalents (component, property, parameter). 4) Any XML elements not in the urn:ietf:params:xml:ns:vcard-4.0 namespace must be mapped to an XML: property in vCard. Note that this restricts extension points to only the level of vCard properties. i.e., you cannot have a non urn:ietf:params:xml:ns:vcard-4.0 element as as parameter. Each xml element at the property level in the XML is mapped to its own XML: property in vcard. Ordering of those is not considered significant. 5) Minimal use of XML attributes on elements. 6) Some structured value types should be broken out into sub-elements in XML, e.g., FN. But other types (DATE) should be left as-is because XML tools typically know how to handle those; originally the icalendar-in-xml draft did actually break out the DATE/DATE-TIME values into sub-elements but we changed that based on the feedback we received. 7) Because components and properties can be mixed in iCalendar we choose to encapsulate each in their own XML element to avoid namespace issues. vCard currently does not support the notion of a sub-component so that requirement is probably not needed unless we anticipate ever wanting sub-components. 8) Enumerated values remain as text, not XML elements. So how does this apply to the current draft (draft-ietf-vcarddav-vcardxml-01)?... [discussion follows]
As expressed in the IETF vCard and CardDAV (VCARDDAV) Working Group Charter:
[the IETF VCARDDAV Working Group will consider] "an XML schema which is semantically identical to vCard in all ways and can be mechanically translated to and from vCard format without loss of data. While vCard has deployed successfully and will remain the preferred interchange format, a standard XML schema which preserves vCard semantics might make vCard data more accessible to XML-centric technologies such as AJAX and XSLT. Such a standard format would be preferable to multiple proprietary XML schemas, particularly if vCard semantics were lost by some of them and a lossy gateway problem resulted..."
vCard XML Schema. Edited by Simon Perreault (Viagénie). IETF Network Working Group, Standards Track Internet Draft. Version -01: 'draft-ietf-vcarddav-vcardxml-01', published October 21, 2009, expires April 24, 2010. 15 pages. Appendix A presents the Relax NG Schema. Produced by members of the IETF vCard and CardDAV (VCARDDAV) Working Group. Abstract: "This document defines the XML schema of the vCard data format." Diff with version -00. See the I-D Tracker and publication announcement.
Details: "vCard (vCard Format Specification is a data format for representing and exchanging information about individuals. It is a text-based format, as opposed to a binary format. This document defines an XML representation for vCard. The underlying data structure is exactly the same, enabling a 1-to-1 mapping between the original vCard format and the XML representation. The XML formatting may be preferred in some contexts where an XML engine is readily available and may be reused instead of writing a stand-alone vCard parser... The general idea is to map vCard parameters, properties, and value types to XML elements. For example, the FN property is mapped to the <fn> element. That element in turn contains a text element whose content corresponds to the vCard property's value. vCard parameters are also mapped to XML elements. They are contained in the <parameters> element, which is contained in property elements... Properties having structured values (e.g. the N property) are expressed by XML element trees. Element names in that tree (e.g., 'surname', 'given', etc.) do not have a vCard equivalent since they are identified by position in plain vCard. Line folding is a non-issue in XML. Therefore, the mapping from vCard to XML is done after the unfolding procedure is carried out. Conversely, the mapping from XML to vCard is done before the folding procedure is carried out..."
vCard Format Specification. Edited by Simon Perreault (Viagénie) and Peter W. Resnick (QUALCOMM Incorporated). Version -09: 'draft-ietf-vcarddav-vcardrev-09'. October 20, 2009, expires April 23, 2010. Produced by members of the IETF vCard and CardDAV (VCARDDAV) Working Group.
"This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.)... Electronic address books have become ubiquitous. Their increased presence on portable, connected devices as well as the diversity of platforms exchanging contact data call for a standard. This memo defines the vCard format, which allows the capture and exchange of information normally stored within an address book or directory application... The text/vcard MIME content type contains contact information, typically pertaining to a single contact or group of contacts...Individual lines within vCard are delimited by the line break, which is a CRLF sequence (ASCII decimal 13, followed by ASCII decimal 10). Long logical lines of text can be split into a multiple-physical-line representation using the following folding technique. Content lines SHOULD be folded to a maximum width of 75 octets. Multi-octet characters MUST remain contiguous. The rationale for this folding process can be found in RFC 5322, Section 2.1.1. A logical line MAY be continued on the next physical line anywhere between two characters by inserting a CRLF immediately followed by a single white space character (space, ASCII decimal 32, or horizontal tab, ASCII decimal 9). The folded line MUST contain at least one character. Any sequence of CRLF followed immediately by a single white space character is ignored (removed) when processing the content type..."
vCard Extensions to WebDAV (CardDAV). Edited by Cyrus Daboo (Apple Inc). IETF Network Working Group, Standards Track Internet Draft. Version -10 'draft-ietf-vcarddav-carddav-10' published November 9, 2009, expires May 13, 2010. 56 pages. See the I-D Tracker.
"This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. Address books containing contact information are a key component of personal information management tools, such as email, calendaring and scheduling, and instant messaging clients. To date several protocols have been used for remote access to contact data... WebDAV (RFC 4918) offers a number of advantages as a framework or basis for address book access and management. Most of these advantages boil down to a significant reduction in design costs, implementation costs, interoperability test costs and deployment costs. A CardDAV address book is modeled as a WebDAV collection with a well defined structure; each of these address book collections contain a number of resources representing address objects as their direct child resources. Each resource representing an address object is called an "address object resource". Each address object resource and each address book collection can be individually locked and have individual WebDAV properties..."
The OASIS WS-Calendar TC Charter notes that "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...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..."
As an example of requirements for scheduling ("negotiating services is agreeing when something should occur, and in auditing when they did occur"), see the NAESB Smart Grid Task Force (SGTF) Recommendation as part of the NIST smart grid priority actions: Requirements Specification for Common Scheduling Mechanism for Energy Transactions, and 'Smart Grid Standards, Strategies and Development' reference document:
This recommendation contains a set of requirements relating to the use of date and time based data elements that are used in transactions for Demand Response Programs. This information is being provided to NIST in order to aid in the development of a standard representation for date/time based data elements derived from an XML representation of iCalendar.
Although there are many other areas where date/time based data elements are used in energy industry transactions this recommendation is limited in scope to only those date/time based data elements that are utilized in Demand Response Programs.
Smart grid interfaces must communicate between domains, that is between different business and consumer entities with different values and approaches (ontologies). Such interfaces must be simplified to bare essentials, and be understandable by parties with different backgrounds and expectations.
To achieve cross-domain understandability, and thereby enhance interoperation, smart grid transactions must use semantic models from different areas developed by different standards groups. Each of these vocabularies is most fully defined in one area. We have agreed, within the NIST process, to use the vocabularies from the appropriate domain experts to compose the message that flow between domains on the smart grid.
For purposes of this document, we define transactions as grid events that occur between domains, or whose effects and outcomes must be communicated between domains. This activity makes no assertions about any other events.
Smart grid transactions communicate three classes of information. They describe events used within the power management and distribution of the grid. They invoke financial or business transactions concerning those transactions. They communicate schedules and interval information for the flows of energy. Per agreement, all semantics relating to Power Management will use the Common Information Model (CIM) from IEC TC57. All financial and market semantics will be based upon the definitions found in ISO 20022 (Financial Documents) and in their most common expression, FIX. All elements relating to schedule and interval will be expressed in the notation of the IETF iCalendar (RFC 5545) standard, as defined in the XML representation of iCalendar developed by CalConnect. The purpose of this approach is to increase interoperation and understanding between domains.
The group primarily associated with the development of interoperable enterprise date, time, and interval standards for the IETF is the Calendaring and Scheduling Consortium (CalConnect). CalConnect and OASIS will work together to define the common communication of date time and interval to meet the needs of smart grid transaction communications as well as for building systems integration, enterprise interaction, and financial transactions. This commonality is anticipated to reduce barriers to interoperation and thereby to expand participation in DR and DER.
The purpose of this action is to define the requirements for standard communication of date, time, schedule, and interval by smart grid actors, with particular attention to demand response (DR). These requirements will be submitted to the OASIS and CalConnect technical committee to define the applicable communication standards to support them..."
OASIS Presents Ground Floor Briefing on WS-Calendar Technical Activity. Slides (PDF) and video recording. "WS-Calendar is a new effort to formalize and standardize the communication of schedule and interval information for Web services. This free webinar on Friday, February 19, 2010 11:00 AM - 12:00 PM EST will provide background and discussion for all those considering participation in the OASIS WS-Calendar Technical Committee. WS-Calendar will address needs common to the enterprise, to facilities operations, to financial instruments, and to Smart Grid operations. The webinar will explain the advantages of defining a standard information model for use in Web services communications within and between domains. Status of recent efforts to update iCalendar and related standards (iTIP and iMIP) within the IETF will be provided. A description of ongoing work to standardize the XML representations not only of iCalendar, but also of Calendar-to-Calendar interactions will be included as well. The webinar will feature a discussion of the anticipated uses of WS-Calendar within other standards efforts, including WSDM, BPEL, EDXL, and oBIX. We will also explore scenarios in Smart Grid, social networking, and in the operation of electric vehicles. Anyone considering participation in the OASIS WS-Calendar Technical Committee, including those involved in domains where the common exchange of scheduling information is critical, such as energy transmission, business process applications, emergency management, and smart buildings should register to attend. Webinar presenters include: (1) Dave Thewlis, Executive Director of CalConnect, the Calendaring and Scheduling Consortium, and convener of the OASIS WS-Calendar Technical Committee; (2) Toby Considine, chair of the OASIS oBIX Technical Committee, member of the OASIS Energy Interoperation and the Energy Market Information Exchange (eMIX) Technical Committees. Update 2010-02-23: A recording of the 19-February-2010 webinar is available, referenced from the OASIS Webinars page. Format: .wmv. Extent: 25.4 MB. Duration: 41 minutes.
"Coordinating Time and Energy." By Toby Considine (University of North Carolina, Chapel Hill). January 24, 2009. Blog. "The best guesses are that half of the electricity generated each year in the North America is wasted due to poor alignment of generation and consumption. The way to align the behaviors of these two groups, each autonomous, and each with quite different values is price signals. As each price signal, and each energy contract, would include a schedule component, we need a standard way to discuss schedules in web services for power negotiations... Utilities want to manage the consumption patterns using a process they refer to as Demand-Response. Demand Response always has a scheduling component. It would be nice to use the same xml object for buildings, energy markets, and demand response. Add in weather arbitrage for distributed generation and more domains need to share common scheduling information. So I went looking for a calendar standard for web services I could use. I as surprised not to find one. I am looking for a small 'micro-specification' that would not exist on its own, but would be incorporated into other specifications. I call this WS-Calendar..."
"IETF Internet Draft: iCalendar XML Representation." By Steven Lees (Microsoft). June 12, 2009. Posting to the 'ietf-calsify' discussion list. "Last week Cyrus Daboo, Mike Douglas and I submitted an Internet Draft that specifies an XML format for iCalendar. The draft was developed by the XML technical committee in CalConnect (http://calconnect.org), with input from representatives from Sun, RPI, Apple, Microsoft, and others. The draft 'draft-daboo-et-al-icalendar-in-xml-00.txt' is [here]. As you probably know, there have been some prior attempts to create an XML iCalendar specification... There was a consensus among CalConnect members that there is enough use of one-off XML formatted calendar data to make it worth giving this another try. My question for you all is whether you're interested in working on an XML iCalendar format specification at this time. There's a vCard XML format draft currently under discussion in the vcarddav group [...] and it would be great to develop an iCal XML format at the same time...."
"XML iCalendar: Jon Udell's Interviews with Innovators." The Conversations Network. July 09, 2009. Download the MP3 audio file. "There's a new effort to define an XML representation for iCalendar, the venerable standard for exchanging calendar information. In this episode of Interviews with Innovators, host Jon Udell talks with two of the authors of the proposed specification — Mike Douglass and Steven Lees — about why it's needed, what kinds of problems it will and won't solve, and how the capabilities that iCalendar enables compare and contrast with those enabled by the newer CalDAV standard... Mike Douglass spent many years in the mainframe world ending that period after a move from the UK to Rensselaer Polytechnic Intitute, Troy NY, transitioning via modula-3 to the world of Java, then through accident or design into the world of calendars. He joined CalConnect shortly after it's first meeting to facilitate the work with bedework, which led to his involvement with CalDAV, the icalendar XML format and chair of the timezones committee... Steven Lees is the program manager for FeedSync at Microsoft and the chair of the XML Technical Committee in CalConnect. TC XML is currently working to define a common XML format for iCalendar data so that we can improve the exchange of calendaring data between different applications and services... More test suites are needed, virtual test bed with test data, make services available to non-members also..."
"Why We Need an XML Representation for iCalendar." Jon Udell. Blog. July 23, 2009. "On this week's Innovators show I got together with two of the authors of a new proposal for representing iCalendar in XML. Mike Douglass is lead developer of the Bedework Calendar System, and Steven Lees is Microsoft's program manager for FeedSync and chair of the XML technical committee in CalConnect, the Calendaring and Scheduling Consortium. What's proposed is no more, but no less, than a well-defined two-way mapping between the current non-XML-based iCalendar format and an equivalent XML format... At first glance, the XML version [in my example] just seems verbose. So why bother? Because the iCalendar format can be tricky to read and write, either directly (using eyes and hands) or indirectly (using software). That's especially true when, as is typical, events include longer chunks of text than you see here. I make an analogy to the RSS ecosystem. When I published my first RSS feed a decade ago, I wrote it by hand. More specifically, I copied an existing feed as a template, and altered it using cut-and-paste. Soon afterward, I wrote the first of countless scripts that flowed data through similar templates to produce various kinds of RSS feeds. Lots of other people did the same, and that's part of the reason why we now have a robust network of RSS and Atom feeds that carries not only blogs, but all kinds of data packets. Another part of the reason is the Feed Validator which, thanks to heroic efforts by Mark Pilgrim and Sam Ruby, became and remains the essential sanity check for anybody who's whipping up an ad-hoc RSS or Atom feed. No such ecosystem exists for iCalendar. I've been working hard to show why we need one, but the most compelling rationale comes from a Scott Adams essay: 'I think the biggest software revolution of the future is that the calendar will be the organizing filter for most of the information flowing into your life'..."
"Explanation and Background of Smart Grid Schedule Approaches." By Toby Considine (University of North Carolina at Chapel Hill). December 29, 2009. Memo explaning why the WS-Calendar TC proposers chose iCalendar for time synchronization of the smart grid. "There are two quite different time-related tasks: time synchronization and schedule alignment. As those who grew up like me watching Mission Impossible know, every episode begins with synchronizing the watches. What they actually do during the show/mission is alignment based on that synchronization. Performance alignment introduces the most interesting plot twists to the show; performance alignment is also at the heart of several of the most important issues of smart grids. Either is useless unless time synchronization has occurred already. [NAESB] PAP13 is primarily involved with issues of time synchronization and PAP04 with alignment. The tasks of performance alignment and many and varied. There will be a DR event at 3:15 today. In 6 hours, the price will be half of what it is now — and will stay there for three hours. I would like to buy power with this power profile during the 6 hours beginning with 4:00 next Tuesday... Performance alignment is not only a concern to smart grid issues. Smart grids need to align and coordinate response off of the grid. Buildings should respond to the scheduled alignment. Business processes should be reviewed to understand if the response makes sense to the business. Financial instruments need to allow for the purchase and sale of energy resources available only in small windows, whether that window is immediate or in the future. Just as the incentive for participating in smart energy must be understood across domain boundaries (dollars) so the time interval that is the focus of the decision must be understood across domain boundaries. This is why we have reached out to the group, the Calendaring and Scheduling Consortium (CalConnect) that works with enterprise schedules and calendar interactions to define the common element of scheduling and interval management..."
"New iCalendar XML Format Draft." By Tim Hare. Posted to the 'ietf-calsify' list. June 13, 2009. "One of the best use cases for iCalendar-as-XML is for providing calendar 'feeds', I think, and as the draft says leveraging the available XML tools. At a minimum it would shorten development time for handling calendar data. Jon Udell (also of Microsoft) has been writing a lot recently about gathering calendar information from many different sources (for example, 'Scribbling in the margins of iCalendar' )... I believe one of the goals of an XML form should be to provide an Atom/RSS-compatible set of XML to further that type of thing. While not as critical to organizations internally, as say, meeting scheduling, publishing of calendar information can be critical. My current employer, a US state transportation department, is required to hold many public hearings and public bid-openings in regard to large construction projects. Providing that calendar information in a format useful to the citizenry would be a major plus ... I think it would also be useful to discuss the opposite (but simpler?) transform: from XML-based calendar info to iCalendar. It seems to me that once something is available in XML, much development work centers around that because of smaller development cost. That means that more established tools built around the iCalendar format will need a method of creating an iCalendar input from an XML document, to allow for interoperability..."
Approved specifications produced by the WS-Calendar TC are available from the OASIS Library repository. Draft deliverables are available in the TC's Kavi repository.
Committee Draft 01 for Public Review (September-November 2010)
WS-Calendar Version 1.0.
Committee Draft 01. 17-September-2010. Edited by Toby Considine (University of
North Carolina, Chapel Hill) and Mike Douglass (Rensselaer Polytechnic Institute). 76 pages. See the file listing for the complete review package in ZIP format (XML .XSD schema files, RDDL, EAP). Appendices: "A. Acknowledgements"; "B. An Introduction to Internet Calendaring"; "C. Overview of WS-Calendar, its Antecedents and its Use". As announced [bis], public review for Committee Draft 01 was scheduled for 24-September-2010 through 23-November-2010. Source for CD-01 Public Review Version in the OASIS Library: HTML, PDF, Word /.doc.
"WS-Calendar describes a limited set of message components and interactions providing a common basis
for specifying schedules and intervals to coordinate activities between services. The specification
includes service definitions consistent with the OASIS SOA Reference Model and XML vocabularies for
the interoperable and standard exchange of: (1) Schedules, including sequences of schedules; (2) Intervals, including sequences of intervals. These message components describe schedules and intervals future, present, or past (historical). The definition of the services performed to meet a schedule or interval depends on the market context in which that service exists. It is not in scope for this TC to define those markets or services..."
Conceptual Overview of
WS-Calendar. Understanding Inheritance Using the Semantic Elements of Web Services.. An OASIS WS-Calendar TC
White Paper. Version: CD01. Edited by Toby Considine on behalf of the OASIS WS-Calendar Technical Committee.
15-September-2010. 13 pages. Source: HTML,
"This White Paper explains some of the issues in generic service coordination as an aid to understanding how and when to use WS-Calendar. WS-Calendar defines calls and semantics to perform temporal alignment in web services interactions. Short running services traditionally have been handled as if they were instantaneous, and have used just-in-time requests for scheduling. Longer running processes, including physical 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. WS-Calendar extends the well-known semantics and interactions built around iCalendar and applies them to service coordination..."
- OASIS WS-Calendar TC:
- Calendaring and Scheduling Consortium (CalConnect):
- IETF Working Groups:
|Receive daily news updates from Managing Editor, Robin Cover.|