This document was last revised or approved by the OASIS Web Services Calendar (WS-Calendar) TC on the above date. The level of approval is also listed above. Check the "Latest version" location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee's email list. Others should send comments to the Technical Committee by using the "Send A Comment" button on the Technical Committee's web page at http://www.oasis-open.org/committees/ws-calendar/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/ws-calendar/ipr.php).

Citation format:

When referencing this specification the following citation format should be used:

[WS-Calendar]

WS-Calendar Version 1.0. 30 July 2011. OASIS Committee Specification 01. http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/cs01/ws-calendar-spec-v1.0-cs01.html.

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

Table of Contents

1 Introduction. 7

1.1 Terminology. 8

1.2 Normative References 8

1.3 Non-Normative References 9

1.4 Contributions 10

1.5 Namespace. 10

1.6 Naming Conventions 11

1.7 Editing Conventions 11

1.8 Architectural References 11

1.9 Semantics 11

2 Overview of WS-Calendar 16

2.1 Approach taken by the WS-Calendar Technical Committee. 16

2.2 Communicating Schedules and Service Performance. 16

2.2.1 Which Time? UTC vs. Local Time. 17

2.3 Overview of This Document 17

2.4 Security Considerations 17

3 PART ONE: Information model for WS-Calendar 19

3.1 Intervals, Temporal Relations, and Sequences 19

3.1.1 Core Semantics derived from [XCAL] 19

3.1.2 Intervals 20

3.1.3 Connecting the Intervals 21

3.1.4 Sequences: Combining Intervals 22

3.1.5 State Changes 25

3.2 Attachments and Tolerance. 26

3.2.1 Attachment and the Artifact 26

3.2.2 Tolerance: What is Timely Performance. 27

3.3 Using Sequences: referencing, modifying, and remote access 28

3.3.1 References and Inheritance. 28

3.3.2 Gluons and Sequences 31

3.3.3 Inheritance rules for Gluons 32

3.3.4 Optimizing the expression of a Partition. 33

3.3.5 Notifying Partners of Process Availability. 36

3.3.6 Other Scheduling Scenarios 38

3.4 Time Stamps 40

3.4.1 Time Stamp Realm Discussion. 41

4 Conformance and Rules for WS-Calendar and Referencing Specifications 42

4.1 Introduction. 42

4.2 Conformance Rules for WS-Calendar 42

4.2.1 Inheritance in WS-Calendar 42

4.2.2 Specific Attribute Inheritance. 42

4.2.3 General Conformance Issues 43

4.2.4 Covarying Elements 43

4.2.5 Conformance of Intervals 43

4.2.6 Conformance of Bound Intervals and Sequences 44

4.3 Conformance Rules for Specifications Claiming Conformance to WS-Calendar 44

4.4 Security Considerations 44

A. Acknowledgements 45

B. An Introduction to Internet Calendaring. 46

B.1.4 Extensibility. 47

B.2 Calendar data access and exchange protocols 47

B.2.1 Internet Calendar Subscriptions 47

B.2.2 CalDAV. 47

B.2.3 ActiveSync/SyncML. 48

B.2.4 CalWS. 48

B.2.5 iSchedule. 48

B.3 References 48

C. Overview of WS-Calendar, its Antecedents and its Use. 49

C.1 Scheduling Sequences 50

C.1.1 Academic Scheduling example. 50

C.1.2 Market Performance schedule. 51

D. Revision History. 52

Tables

Index of Tables

Table 1‑1: Namespaces used in this specification. 10

Table 1‑2: Schemas and Extensions Used in this Specification. 10

Table 1‑3: Semantics: Foundational Elements 11

Table 1‑4: Semantics: Relations, Limits, and Constraints 12

Table 1‑5: Semantics: Inheritance. 13

Table 1‑6: Semantics: Describing Intervals 14

Table 3‑1: Elements of Intervals 20

Table 3‑2: Temporal Relationships 21

Table 3‑3: Elements of a WS-Calendar Attachment 26

Table 3‑4: Tolerance Elements 27

Table 3‑5: Gluon Elements 29

Table 3‑6 Gluon Inheritance rules 32

Table 3‑7: Elements of Time Stamps 40

Index of Examples

Example 3‑1: An Unanchored Interval 21

Example 3‑2: Temporal Relationship. 21

Example 3‑3: Temporal Relationship with Gap. 22

Example 3‑4: Temporal Relationship without Gap. 22

Example 3‑5: Introducing the Sequence. 22

Example 3‑6: An Anchored Sequence. 23

Example 3‑7 State Change communication using Zero Duration Interval 25

Example 3‑8 State Change communication using Event without Duration or End. 25

Example 3‑9: Use of an Attachment with inline XML artifact 26

Example 3‑10: Use of an Attachment with external reference. 26

Example 3‑11: Interval with inline XML artifact and optional specified Performance. 28

Example 3‑12: Sequence with Performance defined in the Gluon. 31

Example 3‑13: Partition with Duration and Relationship defined in the Gluon. 33

Example 3‑14: Vavailability. 36

Example 3‑15 Gluon publishing availability of pre-existing sequence. 37

Example 3‑16: Standard Sequence with Ramp-Up and Ramp Down. 39

1 Introduction

The information model of WS-Calendar is intended to be used to define information payloads for Web services and Service-style interactions [SOA-RM]. Placing these requirements in context requires a brief overview of service requirements.

Agreement on when something should or did occur is fundamental to negotiating service use. Negotiated services must be audited to understand timely performance. Short running services traditionally have been handled as if they were instantaneous, and have handled scheduling through just-in-time requests. 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. Pre-existing approaches that rely on direct control of such services by a central system increases integration costs and reduce interoperability as they require the controlling agent to know and manage multiple lead times.

Not all services are requested one time as needed. Processes may have multiple and periodic occurrences. An agent may need to request identical processes on multiple schedules. An agent may request services to coincide with or to avoid human interactions. Service performance may be required on the first Tuesday of every month, or in weeks in which there is no payroll, to coordinate with existing business processes. Service performance requirements may vary by local time zone. A common schedule communication must support diverse requirements.

Web services already coordinate a number of physical processes. Web services for building-based systems include the standards [oBIX], BACnet/WS[1] LON-WS[2], OPC UA[3], as well as a number of proprietary systems. The European research and advanced development project SIRENA (Service Infrastructure for Real time Embedded Networked Applications) explored SOA for buildings, factories and devices, including SODA (Service Oriented Device Architecture). SOA4D[4] (Service-Oriented Architecture for Devices) offers a collaborative open source development web platform, including implementations ([SOAP] messaging, [WS-Management], [WS-Security], [DPWS]) adapted to the specific constraints of embedded devices. There is a growing interest in coordinating the activities of things, building systems, industrial processes, homes, with human enterprise activities. In particular, if building systems coordinate with the schedules of the building's occupants, they can reduce energy use while improving performance.

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; mechanisms proposed include communicating different prices at different times. These and other efforts can benefit from a common cross-domain, cross specification standard for communicating schedule and interval.

For human interactions and human scheduling, the well-known iCalendar format addresses these problems. Prior to WS-Calendar, there has been no comparable standard for web services. As an increasing number of physical processes become managed by web services, the lack of a similar standard for scheduling and coordination of services becomes critical.

The WS-Calendar Technical Committee (TC) based its work upon the iCalendar specification as updated in 2009 (IETF [RFC5545] and its the XML serialization [XCAL], currently (2011-05) on a standards track in the IETF. The specification adopts the semantics and vocabulary of iCalendar for application to the completion of service contracts and inter-process interactions. Members of the Calendaring and Scheduling Consortium (CalConnect.org) developed both updates to IETF specifications and provided advice to this TC.

While this specification (WS-Calendar) defines the use of core semantic elements from iCalendar, no part of this document is intended to prevent the use of other semantic elements from iCalendar from being used. WS-Calendar describes the minimal use of that standard, not the maximal.

Everything with the exception of all examples, all appendices, and the introduction is normative unless otherwise specifically noted.

1.1 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]

1.2 Normative References

CalendarResource C. Joy, C. Daboo, M Douglass, Schema for representing resources for calendaring and scheduling services, http://tools.ietf.org/html/draft-cal-resource-schema-03, (Internet-Draft), November 2010.

FreeBusy E York. Freebusy read URL, http://www.calconnect.org/pubdocs/CD0903%20Freebusy%20Read%20URL%20V1.0.pdf, April 2009

REST T Fielding, Architectural Styles and the Design of Network-based Software Architectures, http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm., Dissertation, 2000

ISO8601 ISO (International Organization for Standardization). Representations of dates and times, third edition, December 2004, (ISO 8601:2004)

RFC2119 S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/RFC/RFC2119.txt, IETF RFC2119, March 1997.

RFC2616 R Fielding, et al. et al, Hypertext Transfer Protocol -- HTTP/1.1 http://tools.ietf.org/html/RFC2616, IETF RFC2616, draft standard, June, 1999

RFC3339 G Klyne, C Newman, Date and Time on the Internet: Timestamps
http://tools.ietf.org/html/rfc3339, IETF RFC3339 proposed standard, July 2002

RFC4791 Daboo, et al. Calendaring Extensions to WebDAV (CalDAV), http://www.ietf.org/rfc/rfc4791.txt. IETF RFC 4791, proposed standard, March 2007

RFC5545 B. Desruisseaux Internet Calendaring and Scheduling Core Object Specification (iCalendar), http://www.ietf.org/rfc/rfc5545.txt, IETF RFC5545, proposed standard, September 2009

RFC5546 C. Daboo iCalendar Transport-Independent Interoperability Protocol (iTIP), http://www.ietf.org/rfc/rfc5546.txt, IETF RFC5546, proposed standard, December 2009.

RFC5988 M. Nottingham, Web Linking, http://tools.ietf.org/html/rfc5988, IETF RFC5998, proposed standard, October 2010.

RFC6047 A. Melnikov, iCalendar Message-Based Interoperability Protocol (iMIP), http://tools.ietf.org/html/rfc6047, IETF RFC6047, December 2010.

SOA-RM OASIS Standard, Reference Model for Service Oriented Architecture 1.0, http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf , October 2006.

SOAP M Gudgin, M Hadley, N Mendelsohn, J Moreau, H Nielsen, A Karmarkar,
SOAP Version 1.2 Part 1: Messaging Framework, W3C Recommendation http://www.w3.org/TR/soap12-part1/, W3C Recommendation, April 2007

Vavailability C. Daboo, B. Desruisseaux, Calendar Availability, http://tools.ietf.org/html/draft-daboo-calendar-availability-02, IETF Internet Draft, April 2011

xCal C. Daboo, M Douglass, S Lees xCal: The XML format for iCalendar, http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-08, IETF Internet-Draft, April 2011.

XPATH A Berglund, S Boag, D Chamberlin, M Fernandez, M Kay, J Robie, J Simeon, XML Path Language (XPath) 2.0 (Second Edition), http://www.w3.org/TR/xpath20/, W3C Recommendation, December 2010.

XLINK S DeRose, E Maler, D Orchard, N Walsh, XML Linking Language (XLink) Version 1.1, http://www.w3.org/TR/xlink11/ May 2010.

XPTR P Grosso, E Maler, J Marsh, N Walsh, XPointer Framework, http://www.w3.org/TR/xptr-framework/ W3C Recommendation, March 2003
P Grosso, E Maler, J Marsh, N Walsh, XPointer element() Scheme, http://www.w3.org/TR/xptr-element/, W3C Recommendation March 2003

XML NAMES T Bray, D Hollander, A Layman, R Tobin, HS Thompson "Namespaces in XML 1.0 (Third Edition)" http://www.w3.org/TR/xml-names/ W3C Recommendation, December 2009

XML SCHEMA PV Biron, A Malhotra, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/xmlschema-2/ October 2004.

XRD OASIS XRI Committee Draft 01, Extensible Resource Descriptor (XRD) Version 1.0, http://docs.oasis-open.org/xri/xrd/v1.0/cd01/xrd-1.0-cd01.pdf October 2009.

1.3 Non-Normative References

DPWS T Nixon, A Regnier, D Driscoll, Antoine Mensch, Devices Profile for Web Services 1.1, http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01, July 2009

NIST Framework NIST Framework and Roadmap for Smart Grid Interoperability Standards, Office of the National Coordinator for Smart Grid Interoperability, Release 1.0, NIST Special Publication 1108, http://www.nist.gov/public_affairs/releases/upload/smartgrid_interoperability_final.pdf.

NAESB Requirements NAESB Smart Grid Requirements (awaiting publication) (draft contributed)
http://lists.oasis-open.org/archives/ws-calendar-comment/201005/doc00000.doc, May 2010

RFC4918 L. Dusseault, HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). http://tools.ietf.org/html/rfc4918 IETF RFC 4918, proposed standard, June 2007

TZDB P Eggert, A.D. Olson, "Sources for Time Zone and Daylight Saving Time Data", http://www.twinsun.com/tz/tz-link.htm

Time Zone Recommendations, CalConnect, CalConnect EDST (Extended Daylight Savings Time) Reflections and Recommendations, Version: 1.1,
http://www.calconnect.org/pubdocs/CD0707%20CalConnect%20EDST%20Reflections%20and%20Recommendations%20V1.1.pdf
October 2010

Time Zone Service, M Douglas, C Daboo, Timezone Service Protocol, Draft RFC,IETF, http://datatracker.ietf.org/doc/draft-douglass-timezone-service/

WS-Management DMTF Standard, Web Services for Management, http://www.dmtf.org/sites/default/files/standards/documents/DSP0226_1.0.0.pdf
April 2010

WS-Security K Lawrence, C Kaler, A Nadalin, R Monzillo, P Hallam-Baker, Web Services Security: 4 SOAP Message Security 1.1, http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf, February 2006

WSDL R Chinnici, J Moreau, A Ryman, S Weerawarana, Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language http://www.w3.org/TR/wsdl20/, W3C Recommendation, June 2007.
R Chinnici, H Haas, A Lewis, J Moreau, D Orchard, S Weerawarana, Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts, http://www.w3.org/TR/wsdl20-adjuncts/, W3C Recommendation, June 2007.

1.4 Contributions

The NIST Roadmap for Smart Grid Interoperability Standards [NIST Framework] requested that many standards development organizations (SDOs) and trade associations work together closely in unprecedented ways. An extraordinary number of groups came together and contributed effort, and time, requirements, and documents. The North American Energy Standards Board (NAESB) oversaw meetings with many representatives from every energy sector to contribute requirements to the TC. These meetings were presided over by Jonathan Booe to support the Roadmap's Priority Action Plan 04 (PAP04), a common specification of time and schedule.

NAESB Smart Grid Standards Development Subcommittee:

The following documents are password protected. For information about obtaining access to these documents, please visit www.naesb.org or contact the NAESB office at (713) 356 0060.

Wholesale http://www.naesb.org/member_login_check.asp?doc=fa_2010_weq_api_6_b_ii.doc

Retail http://www.naesb.org/member_login_check.asp?doc=fa_2010_retail_api_9_b_ii.doc

1.5 Namespace

The XML namespace [XMLNAMES] URI that MUST be used by implementations of this specification is:

urn:ietf:params:xml:ns:icalendar-2.0

Table 1‑1 lists the XML schemas that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant.

Table 1‑1: Namespaces used in this specification

Prefix	Namespace
xs	http://www.w3.org/2001/XMLSchema
xcal	urn:ietf:params:xml:ns:icalendar-2.0
ts	http://docs.oasis-open.org/ns/ws-calendar/timestamp/201103

The Resource Directory Description Language [RDDL 2.0] document that describes this namespace can be found at http://docs.oasis-open.org/ns/ws-calendar. The normative schemas for WS-Calendar can be found linked from this namespace document. The schemas are listed in Table 1‑2.

Table 1‑2: Schemas and Extensions Used in this Specification

Schema	Description
iCalendar.xsd	Base Schema expressing core iCalendar information
iCalendar-params.xsd	Parameters used in iCalendar objects
iCalendar-props.xsd	Properties of iCalendar objects
iCalendar-valtypes.xsd	Values used by iCalendar
iCalendar-link-extension.xsd	Link extensions based on web linking [RFC5998] to define relationships between Components.
iCalendar-wscal-extensions.xsd	Extensions to iCalendar to support service functionality
iCalendar-bw-extensions.xsd	Extensions to support integration with Bedeworks server.
iCalendar-ms-extensions.xsd	Extensions to support integration with MS Exchange Server
TimeStamp.xsd	An ancillary information model describing the elements needed to support event forensics

Reviewers can find the schemas at http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/csd03/xsd/.

1.6 Naming Conventions

This specification follows some naming conventions for artifacts defined by the specification, as follows:

For the names of elements and the names of attributes within XSD files, the names follow the lower camelCase convention, with all names starting with a lower case letter. For example,

For the names of types within XSD files, the names follow the lower CamelCase convention with all names starting with a lower case letter prefixed by "type-". For example,

For the names of intents, the names follow the lower camelCase convention, with all names starting with a lower case letter, EXCEPT for cases where the intent represents an established acronym, in which case the entire name is in upper case.

An example of an intent that is an acronym is the "SOAP" intent.

1.7 Editing Conventions

For readability, element names in tables appear as separate words. The actual names are lowerCamelCase, as specified above, and as they appear in the XML schemas.

All elements in the tables not marked as "optional" are mandatory.

Information in the "Specification" column of the tables is normative. Information appearing in the note column is explanatory and non-normative.

All sections explicitly noted as examples are informational and are not to be considered normative.

1.8 Architectural References

WS-Calendar assumes incorporation into services. Accordingly it assumes a certain amount of definitions of roles, names, and interaction patterns. This document relies heavily on roles and interactions as defined in the OASIS Standard Reference Model for Service Oriented Architecture [SOA-RM].

1.9 Semantics

Certain terms appear throughout this document, some with extensive definitions. Table 1‑3 provides definitions for the convenience of the reader and reviewer. Many terms require fuller discussion than is in this section, and are discussed in greater depth in later sections. In all cases, the normative actual definition is the one in this section.

WS-Calendar terminology begins with a specialized terminology for the segments of time, and for groups of related segments of time. These terms are defined in Table 1‑3 through Table 1‑6 below.

Table 1‑3: Semantics: Foundational Elements

Time Segment	Definition
Component	In iCalendar, the primary information structure is a Component. Intervals and Gluons are new Components defined in this specification.
Duration	Well-known element from iCalendar and [XCAL], Duration is the length of an event scheduled using iCalendar or any of its derivatives. The [XCAL] duration is a data type using the string representation defined in the iCalendar duration.
Interval	The Interval is a single Duration derived from the common calendar Components as defined in iCalendar ([RFC5545]). An Interval is part of a Sequence. An entire Sequence can be scheduled by scheduling a single Interval in that sequence. For this reason, Intervals are defined through Duration rather than through dtStart or dtEnd.
Sequence	A Sequence is a set of Intervals with defined temporal relationships. Sequences may have gaps between Intervals, or even simultaneous activities. A Sequence is re-locatable, i.e., it does not have a specific date and time. A Sequence may consist of a single Interval. A Sequence may optionally include a Lineage. A Sequence can be scheduled multiple times through repeated reference by different Gluons. Intervals are defined through their Duration, and the schedule, dtEnd or dtStart, is applied to the Sequence as a whole.
Partition	A Partition is a set of consecutive Intervals. The Partition includes the trivial case of a single Interval. Partitions are used to define a single service or behavior that varies over time. Examples include energy prices over time and energy usage over time.
Gluon	A gluon is influences the serialization of Intervals in a Sequence, though inheritance and through schedule setting. The Gluon is similar to the Interval, but has no service or schedule effects until applied to an Interval or Sequence.
Artifact	An Artifact is the thing that occurs during an Interval. WS-Calendar uses the Artifact as a placeholder. The contents of the Artifact are not specified in WS-Calendar; rather the Artifact provides an extension base for the use of WS-Calendar in other specifications. Artifacts may inherit elements as do Intervals within a Sequence.

WS-Calendar works with groups of Intervals that have relationships between them. These relations constrain the final instantiation of a schedule-based service. Relations can control the ordering of Intervals in a Sequence. They can describe when a service can be, or is prevented from, being invoked. They establish the parameters for how information will be shared between elements using Inheritance. The terminology for these relationships is defined in Table 1‑4.

Table 1‑4: Semantics: Relations, Limits, and Constraints

Term	Definition
Link	The Link is used by one WS-Calendar object to reference another. A link can reference either an internal object, within the same calendar, or an external object in a remote system.
Relationship	Relationships link between Components for Binding. ICalendar defines several relationships, but WS-Calendar uses only the CHILD relationship, and that only to bind Gluons to each other and to Intervals.
Temporal Relationship	Temporal Relationships extend the [RFC5545] Relationships to define how Intervals become a Sequence by creating an order between Intervals. The Predecessor Interval includes a Temporal Relation, which references the Successor Interval. When the start time and Duration of one Interval is known, the start time of the others can be computed through applying Temporal Relations.
Availability	Availability expresses the range of times in which an Interval or Sequence can be Scheduled. Availability often overlays or is overlaid by Busy. Availability can be Inherited.
Busy	Busy expresses the range of times in which an Interval or Sequence cannot be Scheduled. Busy often overlays is overlaid by Availability. Busy can be Inherited.
Child, Children	The CHILD relationship type (rel_type) defines a logical link (via URI or UID) from parent object to a child object. A Child object is the target of one or more CHILD relationships and may have one to many Parent objects.
Parent [Gluon]	A Gluon (in a Sequence) that includes a CHILD relationship parameter type (rel_type) defines a logical link (via URI or UID) from parent object to a child object. A Parent Component contains one or more CHILD Relationships

WS-Calendar describes how to modify and complete the specification of Sequences. WS-Calendar calls this process Inheritance and specifies a number of rules that govern inheritance. Table 1‑5 defines the terms used to describe inheritance.

Table 1‑5: Semantics: Inheritance

Term	Definition
Lineage	The ordered set of Parents that results in a given inheritance or execution context for a Sequence.
Inheritance	Parents bequeath information to Children that inherit them. If a child does not already possess that information, then it accepts the inheritance. WS-Calendar specifies rules whereby information specified in one informational object is considered present in another that is itself lacking expression of that information. This information is termed the Inheritance of that object.
Bequeath	A Parent Bequeaths attributes (Inheritance) to its Children.
Inherit	A Child Inherits attributes (Inheritance) from its Parent.
Covarying Attributes	Some attributes are inherited as a group. If any member of that group is expressed in a Child, all members of that group are deemed expressed in that Child, albeit some may be default values. These characteristics are called covarying or covariant. A parent bequeaths covarying characteristics as a group and a child accepts or refuses them as a group.
Decouplable Attributes	Antonym for Covarying Attributes. Decouplable Attributes can be inherited separately.

As Intervals are processed, as Intervals are assembled, and as inheritance is processed, the information conveyed about each element changes. When WS-Calendar is used to describe a business process or service, it may pass through several stages in which the information is not yet complete or actionable, but is still a conforming expression of time and Sequence. Table 1‑6 defines the terms used when discussing the processing or processability of Intervals and Sequences.

During the life-cycle of communications concerning Intervals, different information may be available or required. For service performance, Start Duration and the Attachment Payload must be complete. These may not be available or required during service advertisement or other pre-execution processes. Table 1‑6 defines the language used to discuss how the information in an Interval is completed.

Table 1‑6: Semantics: Describing Intervals

Term	Definition
Designated Interval	An Interval that is referenced by a Gluon is the Designated Interval for a Series. An Interval can be Designated and still not Anchored.
Anchored	An Interval is Anchored when it includes a Start or End, either directly or through Binding. A Sequence is Anchored when its Designated Interval is Anchored.
Unanchored	An Interval is Unanchored when it includes neither a Start or an End, either internally, or through Binding. A Sequence is Unanchored if its Designated Interval Unanchored. Note: a Sequence that is re-used may be Unanchored in one context even while it is Anchored in another.
Binding	Binding is the application of information to an Interval or Gluon, information derived through Inheritance or through Temporal Assignment.
Bound Element	A Bound Element refers to an Element and its Value after Binding, e.g., a Bound Duration.
Bound Interval	A Bound Interval refers to an Interval and the values of its Elements after Binding.
Bound Sequence	A Bound Sequence refers to a Sequence and the values of its Intervals after Binding.
Partially Bound	Partially Bound refers to an Interval or a Sequence which is not yet complete following Binding, i.e., the processes cannot yet be executed.
Fully Bound	Fully Bound refers to an Interval or Sequence that is complete after Binding, i.e., the process can be unambiguously executed when Anchored.
Unbound	An Unbound Interval or Sequence is not itself complete, but must still receive inheritance to be fully specified. A Sequence or Partition is Unbound if it contains at least one Interval that is Unbound.
Constrained	An Interval is Constrained if it is not Anchored and it is bound to one or more Availability or Free/Busy elements
Temporal Assignment	Temporal Assignment determines the start times of Intervals in a Sequence through processing of their Durations and Temporal Relations.
Scheduled	A Sequence or Partition is said to be Scheduled when it is Anchored, Fully Bound, and service performance has been requested.
Unscheduled	An Interval is Unscheduled if it is not Anchored, nor is any Interval in its Sequence Anchored. A Sequence or Partition is Unscheduled if none of its Intervals, when Fully Bound, is Scheduled.
Predecessor Interval	A Predecessor Interval includes a Temporal Relation which references a Successor Interval.
Successor Interval	A Successor Interval is one referred to by a Temporal Relationship in a Predecessor Interval.
Antecedent Interval(s)	Antecedents are an Interval or set of Intervals that precede a given Interval within the same Sequence
Earliest Interval	The set of Intervals at the earliest time in a given Sequence
Composed Interval	A Composed Interval is the virtual Interval specified by applying inheritance through the entire lineage and into the Sequence in accord with the inheritance rules. A Composed Interval may be Bound, Partially Bound, or Unbound.
Composed Sequence	A Composed Sequence is the virtual Sequence specified by applying inheritance through the entire lineage and into the Sequence in accord with the inheritance rules. A Composed Sequence may be Bound, Partially Bound, or Unbound.
Comparable Sequences	Two Sequences are Comparable if and only if the Composed version of each defines the same schedule.

2 Overview of WS-Calendar

A calendar communication without a real world effect is of little interest. That real world effect is the result of a service execution context within a policy context. Practitioners can use WS-Calendar to add communication of schedule and Interval to the execution context of a service. Use of WS-Calendar will align the performance expectations between execution contexts in different domains. The Technical Committee intends for other specifications and standards to normatively reference and claim conformance to WS-Calendar, bringing a common scheduling context to diverse interactions in different domains

2.1 Approach taken by the WS-Calendar Technical Committee

The Technical Committee (TC) based its work upon the iCalendar specification as updated in 2009 (IETF [RFC5545] and its the XML serialization [XCAL], currently (2011-05) on a standards track in the IETF. Members of the Calendaring and Scheduling Consortium (CalConnect.org) developed both updates to IETF specifications and provided advice to this TC. [RFC5545] provides the normative vocabulary for use in this specification.

This committee developed the normative schema (XSD) for iCalendar. This schema, including the schema extensions necessary for the services defined herein, is part of the WS-Calendar specification.

The committee solicited requirements from a range of interests, notably the NIST Smart Grid Roadmap [NIST Framework] and the requirements of the Smart Grid Interoperability Panel (SGIP) as developed by the North American Energy Standards Board (NAESB) [NAESB Requirements]. Others submitting requirements included members of the oBIX technical committee and representatives of the FIX Protocol Association. These requirements are reflected in the semantic elements described in Chapters 3 and 4.

In a parallel effort, the CalConnect TC-XML committee developed a number of schedule and calendar-related services. CalConnect drew on its experience in interoperability between enterprise calendaring systems as well as interactions with web-based calendars and personal digital assistants (PDAs). These services were developed as RESTfull (using [REST]) services by CalConnect and contributed to the WS-Calendar TC. CalConnect also developed and contributed [SOAP] and [WSDL] definitions to this TC.

2.2 Communicating Schedules and Service Performance

Time semantics are critical to process interactions. Services requested differently can have different effects on performance even though they appear to request the same time interval. This is inherent in the concept of a service-oriented architecture.

As defined in the OASIS Reference Model for Service Oriented Architecture 1.0 [SOA-RM], service requests access the capability of a remote system.

The purpose of using a capability is to realize one or more real world effects. At its core, an interaction is "an act" as opposed to "an object" and the result of an interaction is an effect (or a set/series of effects). This effect may be the return of information or the change in the state of entities (known or unknown) that are involved in the interaction.

We are careful to distinguish between public actions and private actions; private actions are inherently unknowable by other parties. On the other hand, public actions result in changes to the state that is shared between at least those involved in the current execution context and possibly shared by others. Real world effects are, then, couched in terms of changes to this shared state

A request for remote service performance is a request for specific real world effects. For process interaction, these effects are expected to occur during a given period. Consider two service providers that offer the same service. One must start planning an hour or more in advance. The second may be able to achieve the service in five minutes. The service start time is the time when that service becomes fully available; that is the time specified in service interactions. Because this service start time and service period are all that matters, the same service can be offered by different providers using quite different technologies.

2.2.1 Which Time? UTC vs. Local Time

Coordinated Universal Time (abbreviated UTC) is a time standard based on International Atomic Time (TAI) with leap seconds added at irregular intervals to compensate for the Earth's slowing rotation.Time zones around the world can be expressed as positive or negative offsets from UTC.

When 2 or more parties attempt to agree on a time, e.g., for a meeting, or when to provide a service, they agree to start at a particular instant of time UTC. They agree on that instant in time by converting from local time, e.g., they want a meeting to start at 13:00 Eastern, 18:00 UK. Our lives and the use of services are bound by local time not by UTC. Experientially, local time is the invariant and UTC is mapped on to it. If a government modifies the rules we adjust the mappings and we shift the UTC time. We still want to meet at 13:00 local or have the heating start at 07:00.

As long as the rules never change this causes no confusion—but they do. Recent experience has included considerable efforts when the rules for the start of Daylight Saving Time (DST) have changed. If all information is in UTC, and no record of the event's basis in the local time and time zone remains, there is no way to re-compute existing contracts. It is often necessary to know if UTC was calculated based on an old or a new rule.

A triplet of Local time + timezoneid + (UTC or offset) always allows the determination if a time is valid. If a recalculation of UTC for that local time + tzid results in a different value from that stored then presumably the DST rules have changed since the data was stored. If one can detect that the scheduled time is no longer valid, one can take corrective action.

The Technical Committee makes no representation as whether UTC or local time are more appropriate for a given interaction. Because WS-Calendar is based on [iCalendar], business practices built upon WS-Calendar can support either. Specifications that claim conformance with this specification may require choices to support their particular business processes.

For a fuller discussion of time zones, consult [Time Service Recommendations] and [Time Zone Service] in the non-normative references.

2.3 Overview of This Document

The specification consists of a standard schema and semantics for schedule and interval information. Often the most important service schedule communications involve series of related services over time, which WS-Calendar defines as a Sequence. These semantic elements are defined and discussed in Section 3. While this specification describes only the use of core semantic elements from iCalendar, no part of this document prevents other semantic elements from iCalendar from also being used.

Section 3.2 introduces notions of tolerance, i.e. what does it mean to be "on time". This section also describes the different ways to associate a service request with each Interval in a Sequence.

Managing information exchanges about a Sequence of events can easily become cumbersome, or prone to error. WS-Calendar defines the Gluon, a mechanism for making assertions about all or most of the Intervals in a Sequence. Intervals can inherit from a Gluon, or they can override locally assertions inherited from the Gluon. Section 3.3 discusses inheritance and parsimony of communication and introduces contract scheduling.

The practitioner must decide whether to use one or the other of these communication protocols, or whether WS-Calendar artifacts are better used when embedded within other messages. These decisions must be based upon the specific application and message content. Specifications that claim conformance to this specification may wish to provide guidance appropriate for the business purposes of that specification.

2.4 Security Considerations

Part 1 describes an information model. The information models can be expressed in any interaction, using any protocol. There are no security aspects of the information model.

Specifications which claim conformance with WS-Calendar may wish to specify security approaches or techniques. Security choices must be based on the business requirements and operational risks of the interaction that those specifications define. As this specification defines a general information model, for use in many interactions, it specifies no security approach.

3 PART ONE: Information model for WS-Calendar

3.1 Intervals, Temporal Relations, and Sequences

WS-Calendar Elements are semantic elements derived from the [XCAL] specification. This set of elements is smaller than those needed for full schedule interaction, and describe the Intervals, Durations, and time-related events that are relevant to service interactions. WS-Calendar uses the elements to build a precise vocabulary of time, Duration, Sequence, and Schedule.

WS-Calendar elements adapt the iCalendar objects to make interaction requirements explicit. For example, in human schedule interactions, different organizations have their own expectations. Meetings may start on the hour or within 5 minutes of the hour. As agents scheduled in those organizations, people learn the expected precision. This precision expectation must be explicit to prevent interoperation problems. This specification defines a performance element to elaborate the simple specification of [XCAL] to make explicit the performance expectations within a scheduled event.

This specification defines common semantics for recording and exchanging event information (Time Stamps).

3.1.1 Core Semantics derived from [XCAL]

The iCalendar data format [RFC5545] is a widely deployed interchange format for calendaring and schedule data. The [XCAL] specification standardizes the XML representation of iCalendar information. WS-Calendar relies on [XCAL] standards and data representation to develop its semantic Components.

3.1.1.1 Time

[ISO8601] defines string formats for the expression of date, time, and duration. [ISO8601] also defines string formats to express the passage of time, herein a Duration. This specification relies extensively on [ISO8601]. Examples of date and time representations include:

Year:

YYYY (eg 1997)

Year and month:

YYYY-MM (eg 1997-07)

Complete date:

YYYY-MM-DD (eg 1997-07-16)

Complete date plus hours and minutes:

YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00)

Complete date plus hours, minutes and seconds:

YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00)

Complete date plus hours, minutes, seconds and a decimal fraction of a second

YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)

This specification is general purpose. Standards that claim conformance to this specification may need to restrict the variability above to improve interoperation within their own interactions.

3.1.1.2 The iCalendar Components (VComponents)

iCalendar and [XCAL] have a number of long defined Component objects that comprise the payload inside of an iCalendar message. These include the VTODO, the VALARM, the VEVENT. (The "v" that begins each element name is there for historic reasons.) The definitions and use of each of the vComponents can be found in [RFC5545].

The vComponents share the same parameters and properties. The distinctions between these informational types are ones of purpose and conformance. The Interval and Gluon are new vComponents; each is derived from the same base type as the other vComponents.

This specification in no way deprecates the pre-existing vComponents. The new components are introduced to support stored sequences of operations and remote invocation. The existing vComponents are extended to support informational payloads for process interaction. A conforming specification can use both old and new vComponents where each makes sense.

The RESTful and SOAP in Parts Two and Three of a future version of this specification support all traditional vComponents as well as the new ones defined here. Conforming information elements MAY be processed using traditional iCalendar-based interactions (CalDAV, et al.) and managed in traditional iCalendar stores.

3.1.1.3 Duration and the Granularity of Time

This specification uses Duration as defined in [ISO 8601] as a data-type throughout. iCalendar makes a number of assumptions about the meaning of time when expressed as duration, i.e., a duration is over when the same common metric is reached in the next such unit. For example, a duration of one day starting at 6:00 AM lasts until 6:00 AM the next day. This becomes important during periods when the meaning of a duration changes. The passage of a month that begins on January 5 is complete on February 5. Another month comes to March 5. Each is expressed using the format "P1M". These durations are, respectively, 31, 28 or 29, and 31 days. In a similar way, Years "P1Y" may be 365 or 366 days long, days "P1D" may be 23, 24, or 25 hours long.

If the intention is to express 30 days, then one should use "P30D" and not "P1M". Similarly, if the intent is to express from now until the same time tomorrow, use "P1D" rather than 24 hours "PT24H".

3.1.2 Intervals

Clear communication of the continuous passage of time is critical to defining service coordination.

The building block for this information model is the Interval. The Interval is a time segment whose length is specified by a Duration. The Interval is a unit of time, and can be bound to service delivery. An Unscheduled Interval has no specified date and time. A Scheduled Interval has a specified start date and time. Intervals can legally contain all elements properties as defined in [RFC5545]. For convenience, the elements essential to coordinating service operations using Intervals are listed in Table 3-1.

An Interval is part of a Sequence. An entire Sequence can be scheduled by scheduling a single Interval in a Sequence. A single Sequence can be scheduled multiple times through repeated reference by different Gluons. It may be useful to consider the Unanchored Sequence as a process subroutine and that a Gluon can be used to invoke that subroutine. For this reason, of the three primary temporal elements (dtStart, dtEnd, and Duration) in a Component, the Duration has primacy in Intervals. Within a Sequence, a maximum of a single Interval MAY have a dtStart or a dtEnd.

Nothing in this section supersedes [RFC5545]. Implementers SHALL refer to those respective specifications [RFC5545] and the [XCAL] specifications for the normative description of each element with the exception of Duration, which is as defined as in [ISO8601].

Table 3‑1: Elements of Intervals

Elements	Description
Dtstamp	Identifies when Interval object was created
Uid	Used to enable unambiguous referencing by other Components
Duration	Identifies length of time for Interval. Duration must be known before an Interval can be transacted, but the Duration may only come through Binding.
DtStart	Scheduled start date and time for Interval. The Start must be known before an Interval can be transacted, but the Duration may only come through Binding.
Attach	In [XCAL], any attachment. In WS-Calendar, the Attach contains the informational payload used by conforming specifications. See section 3.2.
Relation	Relations contain the temporal relations between Intervals that create Sequences. Section 3.1.3. describes Temporal Relations and their use.

An Interval specifies how long an activity lasts. The example below (Example 3‑1) shows a fragment of a WS-Calendar-based message containing a single Unanchored Interval, i.e., it contains neither a dtStart nor a dtEnd. Note that there is no Relationship; there is no need for Relationships until an Interval is incorporated into a Sequence.

Example 3‑1: An Unanchored Interval

<xcal:interval>

<xcal:properties>

<xcal:uid>

<xcal:text>bfe8069a-0c94-4b53-852f-6a2f12639c7e</xcal:text>

</xcal:uid>

<xcal:duration>

<xcal:duration>PT10H</xcal:duration>

</xcal:duration>

</xcal:properties>

</xcal:interval>

3.1.3 Connecting the Intervals

Many iCalendar communications involve more than one Interval. Classic iCalendar [RFC5545] defines relationships internally. [xCAL] uses the extensible expression pattern of Web Links (as described in [RFC5588]) to express the iCalendar relationships PARENT, CHILD, and SIBLING. This specification extends these relationships by adding Temporal Relations. Temporal Relations consist of a reference, a relation, and a Gap that specifies any Duration between Predecessor and Successor.

Unlike most semantic elements in this specification, Temporal Relations are defined in this specification, rather than defined elsewhere and used herein.

Table 3‑2: Temporal Relationships

Temporal Relationship	Short Form	Definition	Example
Gap		Duration indicating the time between the predecessor and the successor. Optional, where missing, Gap is treated as a zero duration	Gap may be positive or negative. In the examples below, the Gap, when present, is 20 minutes.
Finish To Start	FS	As soon as the predecessor Interval finishes, the successor Interval starts.	When sanding is complete, painting begins.
Finish To Finish	FF	The successor Interval continues as long as the predecessor Interval.	The concession stand stops serving 20 minutes after the end of the game.
Start To Finish	SF	The start of the predecessor controls the finish of the successor.	The start of Attendee Check-in controls the end of the Interval "Set up registration booth."
Start To Start	SS	The Predecessor Interval triggers the start of the second task.	20 minutes after the caterer begins work, the dining lines are open.

While simple relationships may be ordered based on which task occurs first (finishToStart), if a later Interval is controlling, other choices may make more useful. For example, if ramp-up time must be completed before run-time, and run-time start is indicated in a contract, it may be useful to specify that the Ramp Interval (Successor) must complete before (startToFinish) the Designated Interval's (Predecessor) scheduled start time. Specifications claiming conformance should consider statements of conformance around Temporal Relationships.

The relationship below indicates that this Interval is to start ten minutes following the finish of the Interval specified.

Example 3‑2: Temporal Relationship

<xcal:related-to>

<xcal:parameters>

<xcal:reltype>

<xcal:text>FS</xcal:text>

</xcal:reltype>

<xcal:gap>

<xcal:duration>PT10M</xcal:duration>

</xcal:gap>

</xcal:parameters>

<xcal:uid>07fb177d-54ea-44ea-8ef5-5b763dc9f0c6</xcal:uid>

</xcal:related-to>

If there is no temporal separation between Intervals, the gap element is optional. The following examples are equivalent expressions to express a relationship wherein both Intervals must start at the same moment.

Example 3‑3: Temporal Relationship with Gap

<xcal:related-to>

<xcal:parameters>

<xcal:reltype>

<xcal:text>FS</xcal:text>

</xcal:reltype>

<xcal:gap>

<xcal:duration>PT10M</xcal:duration>

</xcal:gap>

</xcal:parameters>

<xcal:uid>07fb177d-54ea-44ea-8ef5-5b763dc9f0c6</xcal:uid>

</xcal:related-to>

Leaving out the optional Gap element, we have:

Example 3‑4: Temporal Relationship without Gap

<xcal:related-to>

<xcal:parameters>

<xcal:reltype>

<xcal:text>FS</xcal:text>

</xcal:reltype>

</xcal:parameters>

<xcal:uid>07fb177d-54ea-44ea-8ef5-5b763dc9f0c6</xcal:uid>

</xcal:related-to>

The expressions of a Temporal Relationship in Example 3‑3and Example 3‑4 are equivalent.

Intervals with Temporal Relationships enable the message to express complex temporal relations to form a Sequence. A Sequence consisting of identical consecutive Intervals is named a Partition. As the rules for parsing XML do not mandate preservation of order within a sub-set, we cannot assume that order is preserved when parsing a set of Intervals. For Sequences in WS-Calendar, then, mere order is not enough—a Sequence is a collection of Intervals each of which Interval either refers to or is referred by at least one Interval. Using the references, expressed as Temporal Relations, WS-Calendar describes a single coherent Sequence assembled from a set of Intervals in a collection.

3.1.4 Sequences: Combining Intervals

A Sequence is a collection of Intervals with a coherent set of Temporal Relationships (Table 1‑3). Temporal Relationships are transitive, so that if Interval A is related to Interval B, and Interval B is related to Interval C, then Interval A is related to Interval C. Sequences can also include Gluons (see section 3.3.1, References and Inheritance., but for this section, we will discuss Sequences only as a set of Intervals.

Example 3‑5: Introducing the Sequence

<xcal:vcalendar>

<xcal:components>

<xcal:interval>

<xcal:properties>

<xcal:uid>

<xcal:text>69343fc9-c1da-4cd0-abbd-889716a401d2</xcal:text>

</xcal:uid>

<xcal:duration>

<xcal:duration>PT1H</xcal:duration>

</xcal:duration>

</xcal:properties>

</xcal:interval>

<xcal:interval>

<xcal:properties>

<xcal:uid>

<xcal:text>0ba5a8c0-4eb2-49db-8514-5da18f53caaa</xcal:text>

</xcal:uid>

<xcal:related-to>

<xcal:parameters>

<xcal:reltype>

<xcal:text>FS</xcal:text>

</xcal:reltype>

</xcal:parameters>

<xcal:uid>69343fc9-c1da-4cd0-abbd-889716a401d2</xcal:uid>

</xcal:related-to>

<xcal:duration>

<xcal:duration>PT2H</xcal:duration>

</xcal:duration>

</xcal:properties>

</xcal:interval>

<xcal:interval>

<xcal:properties>

<xcal:uid>

<xcal:text>8edc5ef8-c269-4897-be10-c8a3eb6c8fb6</xcal:text>

</xcal:uid>

<xcal:related-to>

<xcal:parameters>

<xcal:reltype>

<xcal:text>FS</xcal:text>

</xcal:reltype>

<xcal:gap>

<xcal:duration>PT10M</xcal:duration>

</xcal:gap>

</xcal:parameters>

<xcal:uid>0ba5a8c0-4eb2-49db-8514-5da18f53caaa</xcal:uid>

</xcal:related-to>

<xcal:duration>

<xcal:duration>PT3H</xcal:duration>

</xcal:duration>

</xcal:properties>

</xcal:interval>

</xcal:components>

</xcal:vcalendar>

In the example above, the Intervals are 1 hour, 2 hours, and 3 hours long. There is a ten minute period between the second and third periods.

3.1.4.1 Anchoring a Sequence

A Sequence becomes an Anchored Sequence whenever the Designated Interval within the Sequence becomes Anchored. An Interval is Anchored when it has a specific starting date and time (dtstart). A Sequence may become Anchored when a Designated Interval becomes Anchored through Binding. A Gluon may reference a Designated Interval through an external reference, i.e., through referring to a resolvable Uid. A given Sequence may remain Unanchored while being incorporated into many Anchored Sequences through multiple Gluon references each creating a different Bound dtStart.

Example 3‑6: An Anchored Sequence

<xcal:vcalendar>

<xcal:components>

<xcal:interval>

<xcal:properties>

<xcal:uid>

<xcal:text>86879372-6d90-4de3-8267-eae50c774f82</xcal:text>

</xcal:uid>