ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 1 of 26

WS-Calendar Minimal PIM-Conformant Schema Version 1.0

Working Draft 02

22 July 2015

Technical Committee: OASIS Web Services Calendar (WS-Calendar) TC

Chair: Toby Considine (toby.considine@unc.edu), University of North Carolina at Chapel Hill

Editor: Toby Considine (toby.considine@unc.edu), University of North Carolina at Chapel Hill

Additional artifacts: This prose specification is one component of a Work Product which also includes:

XML schemas: (list file names or directory name)

Other parts (list titles and/or file names)

Related work:

This specification is related to:

WS-Calendar Platform Independent Model (PIM) Version 1.0. Edited by W.T. Cox and Toby Considine, latest version: http://docs.oasis-open.org/ws-calendar/ws-calendar-pim/v1.0/cs01/ws-calendar-pim-v1.0-cs01.pdf

WS-Calendar Version 1.0. Edited by Toby Considine and Mike Douglass. Latest version.

http://docs.oasis-open.org/ws-calendar/ws-calendar/v1.0/ws-calendar-1.0-spec.html

Declared XML namespaces:

http://docs.oasis-open.org/ws-calendar/ns/****

Abstract: iCalendar (RFC5545) and its peer specification XCAL (also in WS-Calendar 1.0) is a well-known and long used means to convey schedule-related information. iCalendar makes extensive use of extension and recursion. The WS-Calendar Platform Independent Model (PIM) constrains iCalendar and defines a simpler information model which shares iCalendar semantics and can be used to create as the common basis for any number of Platform Specific Models (PSMs).

Because an information model is abstract, it can apply to many transmission and serialization schemas. The PIM itself does not include a transmission and serialization schemas. Through transitive conformance such PSMs themselves conform to WS-Calendar.

The Minimal PIM-Conformant (MPC) schema defines an XML Schema that conforms just with the PIM. MPC can be used by itself or as a seed-schema for other specifications,

Status: This Working Draft (WD) has been produced by one or more TC Members; it has not yet been voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a Committee Note Draft). The OASIS document Approval Process begins officially with a TC vote to approve a WD as a Committee Draft. A TC may approve a Working Draft, revise it, and re-approve it any number of times as a Committee Draft.

Copyright © OASIS Open 2012-2015. All Rights Reserved.

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,

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 2 of 26

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.

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 3 of 26

Table of Contents

1 Introduction ........................................................................................................................................... 5

1.1 Terminology ........................................................................................................................................ 5

1.2 Normative References ........................................................................................................................ 6

1.3 Non-Normative References ................................................................................................................ 6

1.4 Namespace ......................................................................................................................................... 6

1.5 Naming Conventions .......................................................................................................................... 7

1.6 Editing Conventions ............................................................................................................................ 7

2 Overview of the Minimal PIM-Conformant Schema ............................................................................. 8

2.1 Schedule Semantics from WS-Calendar PIM ..................................................................................... 8

2.2 Schedules and Inheritance ................................................................................................................. 9

2.3 When: Start, End and Duration ......................................................................................................... 10

3 Low Level Semantic Elements ........................................................................................................... 11

3.1 When: Start, End and Duration ......................................................................................................... 11

3.2 Specifying Date and Time ................................................................................................................. 11

3.3 The Duration-based Types ............................................................................................................... 12

3.3.1 Tolerance ................................................................................................................................... 12

3.4 Instance IDs and Links ..................................................................................................................... 13

3.5 Other Simple Types .......................................................................................................................... 14

4 Core Components: Intervals, Sequences, and Gluons ...................................................................... 15

4.1 The Interval ....................................................................................................................................... 15

4.2 Temporal Links and Sequences ....................................................................................................... 16

4.2.1 Temporal Links .......................................................................................................................... 16

4.2.2 Sequences................................................................................................................................. 17

4.3 The Gluon ......................................................................................................................................... 18

5 Enhancing Service Advertising and Request: Recurrence and Availability ....................................... 20

5.1 Recurrence Rules ............................................................................................................................. 20

5.2 Recurrence ....................................................................................................................................... 21

5.3 Availability and VAvailability ............................................................................................................. 21

5.3.1 Availability .................................................................................................................................. 21

5.3.2 VAvailability ............................................................................................................................... 22

6 Conformance ...................................................................................................................................... 24

6.1 Conformance with the Semantic Models of WS-Calendar-PIM ........................................................ 24

Appendix A. Acknowledgments ............................................................................................................. 25

Appendix B. Revision History ................................................................................................................ 26

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 4 of 26

Table of Figures 1

Figure 2-1: Basic Power Object from EMIX .................................................................................................. 9 2

Figure 2-2: WS-Calendar Partition, a simple sequence of 5 intervals .......................................................... 9 3

Figure 2-3: Applying Basic Power to a Sequence ........................................................................................ 9 4

Figure 2-4: Simplifying back to Power in a Single Interval .......................................................................... 10 5

Figure 3-1: Date-Time-Date type ................................................................................................................ 11 6

Figure 3-2: Tolerance .................................................................................................................................. 13 7

Figure 4-1: The Interval ............................................................................................................................... 16 8

Figure 4-2: The Temporal Link .................................................................................................................... 17 9

Figure 4-3: The Gluon ................................................................................................................................. 18 10

Figure 5-1: The Recurrence Rule ............................................................................................................... 20 11

Figure 5-2: Recurrence ............................................................................................................................... 21 12

Figure 5-3: Availability ................................................................................................................................. 22 13

Figure 5-4: VAvailability Type ..................................................................................................................... 23 14

15

16

Table of Tables 17

Table 1-1: Namespaces Used in this Specification ...................................................................................... 6 18

Table 2-1: Core Semantics from WS-Calendar ............................................................................................ 8 19

Table 2-2: WS-Calendar Semantics: Inheritance (non-normative) ............................................................. 10 20

Table 3-1: Date Time Types........................................................................................................................ 11 21

Table 3-2: Performance-related Duration Types......................................................................................... 12 22

Table 3-3: ID-Related Types ....................................................................................................................... 13 23

Table 4-1: High Level Component Types of WS-Calendar MIN ................................................................. 15 24

Table 4-2: Temporal Relations .................................................................................................................... 17 25

Table 5-1: Computable Schedules: Availability and Gluon ......................................................................... 20 26

27

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 5 of 26

1 Introduction 28

All text is normative unless otherwise labeled. 29

iCalendar (RFC5545) and its peer specification XCAL (also in WS-Calendar 1.0) is a well-known and long 30 used means to convey schedule-related information. iCalendar makes extensive use of extension and 31 recursion. The WS-Calendar Platform Independent Model (PIM) constrains iCalendar and defines a 32 simpler information model which shares iCalendar semantics and can be used to create as the common 33 basis for any number of Platform Specific Models (PSMs). 34

The iCalendar model is almost infinitely malleable in the number and manner of intervals in time that it 35 can communicate. Separate intervals exist as separate calendar information objects; a single 36 communication can include any number of these objects. This model is verbose in that each of these 37 calendar information objects must include all distinct information. 38

A key concern for [WS-Calendar] is direct compatibility with xCal, the XML Format for iCalendar defined 39 in [RFC6321]. While this format is flexible, it can offer too much optionality to be easily analyzed. To this 40 end, the TC developed a Platform Independent Model [WS-Calendar PIM] which supports all the 41 functions and messages from WS-Calendar, while restricting extension so that the models can be 42 analyzed and validated. This approach redefined WS-Calendar as what Model Driven Architecture calls a 43 Platform Specific Model (PSM) which conforms to [WS-Calendar PIM] 44

The Platform Independent Model [WS-Calendar PIM] describes how to make use of the general model 45 and semantics defined in [WS-Calendar] when defining information exchanges subject to specific 46 constraints. Artifacts that are conformant with [WS-Calendar PIM] can be transformed into a form that is 47 conformant to [WS-Calendar], even while their expression may not support the general purpose 48 expression required for [WS-Calendar]. 49

[WS-Calendar PIM] is a general specification and makes no assumptions about how its information 50 model is used. [WS-Calendar PIM] has specific rules which define Inheritance as a means to reduce the 51 conveyance of repetitive information. As this specification constrains schedule communications to specific 52 business interactions, these inheritance rules are extended to embrace rules of interaction and rules of 53 process that further reduce the information that must be expressed in each interval. 54

Because an information model is abstract, it can apply to many transmission and serialization schemas. 55 The PIM itself does not include a transmission and serialization schemas. Through transitive 56 conformance such PSMs themselves conform to WS-Calendar. 57

[WS-Calendar PIM] does not define a normative structure for the information conveyed. [WS-Calendar 58 PIM] is an information model, and information models can be conveyed in a number of ways. High speed 59 transaction processing requires more predictable means to convey structured information concerning 60 time-based events, states, and transactions. Even legal and conformant conveyances of calendar 61 information may fail to meet the requirements for basic interoperability requirements [WSI-Basic]. 62

The document defines a normative structure for conveying time series of information that is conformant 63 with [WS-Calendar PIM]. It is the intent of the TC meet the requirements of [WSI-Basic], 64

The Minimal PIM-Conformant (MPC) schema defines an XML Schema that conforms just with the PIM. 65 MPC can be used by itself or as a seed-schema for other specifications,There is a common need to 66 communicate information linked to repetitive intervals of time, for history, for telemetry, for projections, 67 and for bids. Such communications benefit from a common model for conveying these series of 68 information. 69

1.1 Terminology 70

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD 71 NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described 72 in RFC2119. 73

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 6 of 26

1.2 Normative References 74

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

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

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

RFC6321 C. Daboo, M Douglass, S Lees xCal: The XML format for iCalendar, 82 http://tools.ietf.org/html/rfc6321, IETF Proposed Standard, August 2011. 83

vAvailability C. Daboo, M. Douglas: Calendar Availability, https://tools.ietf.org/html/draft-84 daboo-calendar-availability-05 IETF Internet Draft, August 2014. 85

WS-Calendar PIM WS-Calendar OASIS Committee Specification, “WS-Calendar Platform 86 Independent Model (PIM) Version 1.0 CS01”, https://www.oasis-87 open.org/committees/download.php/48936/ws-calendar-pim-v1.0-wd05.pdf 88

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

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

1.3 Non-Normative References 94

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

WSI-BASIC R Chumbley, J Durand, G Pilz, T Rutt , Basic Profile Version 2.0, 98 http://ws-i.org/profiles/BasicProfile-2.0-2010-11-09.html, 99 The Web Services-Interoperability Organization, November 2010 100

WS-Calendar WS-Calendar OASIS Committee Specification, WS-Calendar Version 1.0, July 101 2011, http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/cs01/ws-102 calendar-spec-v1.0-cs01.pdf 103

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

1.4 Namespace 107

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

http://docs.oasis-open.org/ws-calendar/ns/**** 109

Dereferencing the above URI will produce the Resource Directory Description Language [RDDL 2.0] 110 document that describes this namespace. 111

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

Table 1-1: Namespaces Used in this Specification 114

Prefix Namespace

Xs http://www.w3.org/2001/XMLSchema

min http://docs.oasis-open.org/ws-calendar/ns/***

The normative schemas for WS-Calendar MPC can be found linked from the namespace document that 115 is located at the namespace URI specified above. 116

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 7 of 26

1.5 Naming Conventions 117

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

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

<element name="componentType" type="ComponentType"/> 121

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

<complexType name="ComponentType"> 124

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

1.6 Editing Conventions 128

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

All elements in the tables not marked as “optional” are mandatory. 131

Information in the “Specification” column of the tables is normative. Information appearing in the note 132 column is explanatory and non-normative. 133

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

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 8 of 26

2 Overview of the Minimal PIM-Conformant Schema 135

This section provides a non-normative introduction to WS-Calendar and the WS-Calendar PIM. It is 136 provides solely for the convenience of the practitioner. The normative definitions of the [PIM] are found in 137

that specification. 138

[WS-Calendar] defines how to use the semantics of the enterprise calendar communications within 139 service communications. [WS-Calendar PIM] defines a Platform Independent Model and re-defined [WS-140 Calendar] as a semantically richer and more variable conformant Platform Specific Model (PSM). Other 141 Platform Specific Models that conform to [WS-Calendar PIM] transitively conform to [WS-Calendar]. In 142 this manner, [WS-Calendar PIM] defines how conformance to [WS-Calendar] is to be achieved on 143

platforms that cannot themselves interact directly with traditional calendar servers. 144

The Minimal PIM-conformant schema defines a message similar to the simplest [WS-Calendar] 145 messages, with reduced optionality to enhance conformance with [WSI-Basic], and conforming to the 146 [PIM]. 147

2.1 Schedule Semantics from WS-Calendar PIM 148

Without an understanding of certain terms defined in [WS-Calendar PIM], the reader may have difficulty 149 achieving complete understanding of their use in this standard. The table below provides summary 150 descriptions of certain key terms from that specification. This specification does not redefine these terms; 151 they are listed here solely as a convenience to the reader. 152

Table 2-1: Core Semantics from WS-Calendar 153

WS-Calendar Term Description

Artifact The placeholder in a Component that holds that thing that occurs during an Interval. In this specification, the [PIM] Artifact is named the Payload.

Availability Availability provides computable rules for the Intervals during which a particular Gluon will accept a Start. Availability is an anti-fragile pattern informing a service requester when a request will be refused.

Duration Duration is the length of time for an event scheduled using iCalendar or any of its derivatives.

Gluon A Gluon influences the serialization of Intervals in a Sequence, through 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.

Interval The Interval is a single discrete segment, an element of a Sequence, and expressed with a Duration. The Interval is derived from the common calendar Components. An Interval is part of a Sequence.

Link A reference to an internal object within the same calendar, or an external object in a remote system. The Link is used by one Component to reference another.

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.

Recurrence Recurrence computes a set of Starts for a sequence, each of which is treated as if an new Gluon supplied a new Start for the same sequence.

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 9 of 26

WS-Calendar Term Description

Sequence 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, and can be scheduled by scheduling that single Interval in that Sequence.

Normative descriptions of the terms in the table above are in [WS-Calendar PIM]. 154

In [iCalendar], the primary information structure is a Component. Several RFCs have extended iCalendar 155 by defining new Components using a core extensible set of semantics defined in that specification. 156 Components themselves have Parameters. Availability is one such component defined as an [iCalendar] 157

extension. 158

Parameters may themselves include Components. The potentially recursive structure of [iCalendar] 159 Components makes that specification immensely expressive. It also makes [iCalendar], and the closely 160 aligned WS-Calendar 1.0, difficult for certain types of machine processing. The [PIM] 161

This specification eliminates the general extension mechanisms and recursion of iCalendar by eliminating 162 the generic components and parameters. 163

In the list below, Interval, Gluon, and Availability reference Components. Duration, Link, Recurrence, and 164 Relationship are Parameters. A Sequence is set of Components, primarily Intervals and Gluons, but is not 165 itself a Type. 166

2.2 Schedules and Inheritance 167

Nearly every response, every event, every offer, and every interaction can have payloads with values that 168 vary over time, i.e., it a set of intervals can be described using a Sequence of Intervals. Many energy 169 market communications involve information about or a request for power delivered over a single interval 170 of time. Simplicity and parsimony of expression must coexist with complexity and syntactical richness. 171

Consider a request to reduce power consumption in response to market conditions on a smart grid 172 (Demand Response). The simplest demand response is to reduce power for a set interval. 173

174

Figure 2-1: Basic Power Object from EMIX 175

At its simplest, though, WS-Calendar expresses repeating intervals of the same duration, one after the 176 other, and something that changes over the course of the schedule 177

178

Figure 2-2: WS-Calendar Partition, a simple sequence of 5 intervals 179

The PIM specification defines how to spread an object like the first over the schedule. The information 180 that is true for every interval is expressed once only. The information that changes during each interval, is 181 expressed as part of each interval.* 182

* 183

Figure 2-3: Applying Basic Power to a Sequence 184

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 10 of 26

Many communications communicate requirements for a single interval. When expressing market 185 information about a single interval, the market object (Power) and the single interval collapse to a simple 186 model: 187

188

Figure 2-4: Simplifying back to Power in a Single Interval 189

[PIM] calls this pattern Inheritance and specifies a number of rules that govern Inheritance. Table 2-2 190 summarizes those terms defined in WS-Calendar to describe Inheritance that are used in this 191 specification as well. This specification does not redefine these terms; they are listed here solely as a 192 convenience to the reader. 193

Table 2-2: WS-Calendar Semantics: Inheritance (non-normative) 194

Streams Term Definition

Lineage The ordered set of Parents that results in a given inheritance or execution context for a Sequence.

Inherit A Child Inherits attributes (Inheritance) from its Parent.

Inheritance A pattern by which information in Sequence is completed or modified by information from a Gluon. Information specified in one informational object is considered present in another that is itself lacking expression of that information.

Bequeath A Parent Bequeaths attributes (Inheritance) to its Children.

Normative descriptions of the terms in the table above are in [PIM]. 195

This specification uses Inheritance as defined in [PIM]. Each Interval in a Sequence contains an 196 information Payload. Incomplete Payloads are each completed through inheriting information from the 197 Gluon. The Gluon provides the information necessary to fully each Interval in the Sequence. 198

From another perspective, a Gluon acts as a service advertisement point for a potential set of activities in 199 time, and a service request may act as a Gluon to fully bind that schedule that set of activities. 200

2.3 When: Start, End and Duration 201

Any interval can be fully defined by two out of these three elements: when it begins, how long it lasts, and 202 when it ends. With any two, you can compute the third. 203

This specification assigns predominance to how long it lasts, the Duration. This approach is commonly 204 used to request human scheduling, i.e., “Find a time when the three of us can meet for an hour.” Activities 205 are then normally scheduled by Start Time, again to reflect human usage: “We will meet for lunch at 206 Noon”. 207

An application or specification MAY choose to specify the Duration and the End of an event, if this is 208 simpler for its domain. Such a specification MUST make this expectation clear, as allowing a mix of Start 209 and End based requests makes programming and conformance more difficult. For simplicity, in this 210 document, all scheduling is described refining an Interval with a Duration and adding a Start. 211

A service request MAY specify both. For example, a Sequence may be advertised with no fixed duration, 212 and a service request MAY specify both the Duration and the Start. 213

The use of the Start and the End without a definition is discouraged because it reduces flexibility while 214 increasing required computation. 215

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 11 of 26

3 Low Level Semantic Elements 216

This section describes the simple types used to construct WS-Calendar MIN messages. 217

Beyond the conventions of WS-Calendar, the normative specification of Date, Time, and Duration is in 218 [ISO8601]. [RFC5545], which was developed prior to XML implements a subset of [ISO8601]. The XML 219 specification also includes only a subset of that specification. The two subsets are not the same. 220

For those elements in this section that are derived from [ISO8601], the standard XML definitions rather 221 than those of [RFC5545] are used. 222

3.1 When: Start, End and Duration 223

Any interval can be fully defined by two out of these three elements: when it begins, how long it lasts, and 224 when it ends. With any two, you can compute the third. 225

This specification assigns predominance to how long it lasts, the Duration. This approach is commonly 226 used to request human scheduling, i.e., “Find a time when the three of us can meet for an hour.” Activities 227 are then normally scheduled by Start Time, again to reflect human usage: “We will meet for lunch at 228 Noon”. 229

An application or specification MAY choose to specify the Duration and the End of an event, if this is 230 simpler for its domain. Such a specification MUST make this expectation clear, as allowing a mix of Start 231 and End based requests makes programming and conformance more difficult. For simplicity, in this 232 document, all scheduling is described refining an Interval with a Duration and adding a Start. 233

A service request MAY specify both. For example, a Sequence may be advertised with no fixed duration, 234 and a service request MAY specify both the Duration and the Start. 235

The use of the Start and the End without a definition is discouraged because it reduces flexibility while 236 increasing required computation. 237

3.2 Specifying Date and Time 238

To fully qualify the when an activity begins, one must specify both a Date and a Time. A partially qualified 239 starting time might include either a data or a time. Under the principals of inheritance, a Component may 240 convey a time and inherit the start date, or convey a start date and inherit the time. 241

242

Figure 3-1: Date-Time-Date type 243

The DateTimeDate type is used in the following fields throughout the larger components. 244

Table 3-1: Date Time Types 245

Type Descritpion

dtStart The DateTimeDate that indicates when an interval begins. Should not be in any Interval that has a dtEnd.

dtEnd The DateTimeDate that indicates when an interval ends. Should not be in any Interval that has a dtStart.

rDate The Recurrence Date. The rDate is added to a set of dtStarts in Recurrence.

exDate An exDate is excluded from previously computed set of rDates.

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 12 of 26

3.3 The Duration-based Types 246

Duration is a complex string as defined in [ISO8601] that specifies the passage of time. This specification 247

uses the subset of the Duration strings in the native XML data type. A 248

Table 3-2: Performance-related Duration Types 249

Type Descritpion

Duration Duration specifies a passage in time. Duration is an essential element for each fully-bound Interval.

Granularity Granularity describes the “chunkiness” of time. For example, a Intervals of a Sequence may all have durations that are multiples of 1 hour. Such a Sequence has a Granularity of 1H.

Precision Precision defines the accuracy in time required. A service whose outcomes are plus or minus 5 minutes (5m) should not accept a service request with a precision of three seconds (3s).

startBefore startBefore indicates whether it is acceptable for an interval to begin before the requested time. The duration specifies the maximum period in advance of the dtStart that is acceptable.

startAfter startAfter indicates whether it is acceptable for an interval to begin after the requested time. The duration specifies the maximum period after of the dtStart that is acceptable.

endBefore endBefore indicates whether it is acceptable for a [task] to be completed before the requested or computed time. The duration specifies the maximum period in advance of the dtEnd that is acceptable.

endAfter endAfter indicates whether it is acceptable for a [task] to be completed after the requested or computed time. The duration specifies the maximum period beyond the dtEnd that is acceptable.

durationLong durationLong indicates how much longer than the specified duration of an Interval is acceptable

durationShort durationShort indicates how much less than the specified duration of an Interval is acceptable

Many of the Duration-based types are used to exchange performance expectations. Performance is 250 outside the scope of this project. A specification that claims conformance and allows the performance 251 types MUST specify how the performance is to be handled. For example, if a service is unable to comply 252 with the performance request, must it reject the request? 253

3.3.1 Tolerance 254

Tolerance names information about how precise the service must or can be when delivering its service. 255 The Tolerance Type bundles together many of the Duration-derived types into a single object. 256

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 13 of 26

257

Figure 3-2: Tolerance 258

If supplied by the service provider, Tolerance is an indication of the service performance advertised. If 259 supplied by a service requestor, Tolerance is the requested performance. Specifications that use 260 Tolerance SHALL specify whether a Service should accept or refuse a request when it is unable to 261 perform at or better than the requested Tolerance. 262

Specifications that incorporate this specification MAY choose to eliminate Tolerance as a message 263 element. 264

3.4 Instance IDs and Links 265

An Instance UID is a conformed string used to uniquely identify each component and artifact, 266

Table 3-3: ID-Related Types 267

ID Type Descritpion

InstanceUID The Instance UID identifies each instance of a Component. Instance UIDs may be computed.

Link The Link is a foreign InstanceUID, that is a named pointer to another Component.

Relation A Relation is a Link that implements the “Child” relation defined in WS-Calendar. The relation is used in a Gluon, or an artifact acting as a Gluon, to point at a child Gluon or Interval..

Temporal Link

Temporal Links point between Intervals to define a Sequence. A Temporal Link optional includes a Temporal Relation. In the absence of a Temporal Relation, a “FinishToStart” relation is assumed. Temporal Relations are discussed in the section on Sequences.

The InstanceUID MAY be computed based on context, depending on use. Consider the following non-268 normative example: 269

A Sequence is defined through Links between Intervals. That Sequence is not fully 270 Bound. A Gluon may point to the Sequence, binding it. A Specification MAY indicate 271 that the InstanceUID of an Interval in the Bound Sequence is identified by 272 Gluon.InstanceID-Interval.InstanceID. IF it is necessary to store and record the Bound 273 Interval, THEN is may be necessary to re-write the TemporalLinks to use the new 274 computed UIDs. Alternately, a specifation in which Sequences consist of a single 275 Interval, may prefer to never replicate the Bound Sequence. 276

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 14 of 26

A specification claiming conformance MUST specify how these computed InstanceUIDs are computed, or 277 if they are not used at all. 278

3.5 Other Simple Types 279

Just a few other string-derived types are used in this specification. 280

Simple Type Descritpion

TimeZone TimeZone is a constrained string indicating the rules for computing time that apply to an exchange of messages. Defining valid Time Zones is outside the scope of this specification.

Comment The Comment is free-form text that optionally accompanies many of the component in this specification.

281

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 15 of 26

4 Core Components: Intervals, Sequences, and 282

Gluons 283

The interval is the essential element of this specification, it is that thing which can be bound in time, or 284 scheduled. A Sequence names a set of one or more intervals bound together by temporal relationships. A 285 Gluon appears as a degenerate Interval used to complete information in the Sequences it references. 286

Table 4-1: High Level Component Types of WS-Calendar MIN 287

Component Description

Interval An Interval is the essential element of any service, action, or telemetry. When fully bound it conveys the when and for how long the information in the payload will occur. The expression of even an actionable (“Fully Bound”) Interval MAY be incomplete, as the can be inherited. An Interval that is not Fully Bound describes a service that cannot be provided until the missing information is provided.

Sequence A Sequence is a set of temporally related Intervals that can be invoked as a single service. Intervals in a Sequence may occur one after the other or in branches and constraints as defined by the Temporal Relations. A Sequence is Fully Bound when each of its member Intervals is Fully Bound.

The simplest Sequence consists of a single Interval

Gluon A Gluon is an Interval that is not itself actionable, while it influences whether Intervals and Sequences are actionable. Gluons are degenerate Intervals that provide missing information to the Intervals in a Sequence while serving as a handle or service entry point to that Sequence.

For example, a Gluon MAY be used as a service advertisement to advertise a Sequence. A method that invokes that service acts as a Gluon to the first Gluon, making the referenced Sequence actionable.

A Gluon also supports elements not seen in the Interval, i.e., Availability and Recurrence. For clarity, 288 these are ignored in this section, and discussed in Section 4. 289

290

4.1 The Interval 291

The Interval is the essential element of WS. If something is being done, it is what is what is being done 292 and for how long. If something is being measured, it is the period of measurement. 293

The Interval is pictured in Figure 4-1: The Interval: 294

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 16 of 26

295

Figure 4-1: The Interval 296

Note that there is considerable optionality, even for necessary information. Under the model described in 297 the [PIM], information is potentially bequeathed from a lineage of Gluons to an Interval. dtStart, duration, 298

timeZone, tolerance, and even payload MAY be inherited. 299

The Temporal Link cannot be inherited. Temporal Links are used to defined relations between Intervals in 300 a Sequence. 301

4.2 Temporal Links and Sequences 302

Temporal Links convey the relationships between Intervals in a Sequence. 303

Each Interval can be considered as a distinct activity for a period of time. A Sequence is a set of such 304 activities. These activities may follow one after another. There may be mandatory gaps, as in paint drying 305 for at least six hours before the next step. It may be a requirement that two Intervals finish at the same 306 time. 307

If a Sequence describes a ramp-time of activities prior to the Inherited dtStart, then the ramp activities 308 must complete prior to the start time. Similarly, a system MAY need to ramp down at the end of a 309 requested Duration of activity. 310

There is a special case of Sequence in which all Intervals proceed linearly without pause, and all Intervals 311 share a common Duration. A Sequence of this Type is referred to as a Partition. 312

4.2.1 Temporal Links 313

Temporal Links are so named because they convey how Intervals are related in Time. 314

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 17 of 26

315

Figure 4-2: The Temporal Link 316

As defined in the PIM, there are four types of Temporal Relation. Temporal Relations combine with the 317 Duration to describe the sequence. 318

Table 4-2: Temporal Relations defines the Temporal Relations. For this table, the Interval that contains 319 the Temporal Link is considered the Originating Interval. The Interval whose InstanceUID is referenced in 320 the Temporal Link is considered the Referenced Interval. Note that any Interval may be Orginating in one 321 context, and Referenced in another. 322

Table 4-2: Temporal Relations 323

Temporal Relation

Description

finishToStart The Referenced Interval will start after the Originating Interval ends, separated by a defined Duration. If the Duration is absent, then the Referenced Interval will begin immediately on completion of the Originating Interval.

finishToFinish The Referenced Interval finish when the Originating Interval ends, separated by a defined Duration. If the Duration is absent, then the Referenced Interval will finish at the same time as does the Originating Interval. A negative Duration specifies that the Referenced Interval finishes before the Originating Interval does.

startToFinish The Referenced Interval will finish a defined Duration start after the Originating Interval starts, separated by a defined Duration. If the Duration is absent, then the Referenced Interval finish just as the Originating Interval starts. A negative Duration specifies that the Referenced Interval will end before the Originating Interval starts.

startToStart The Referenced Interval will start after the Originating Interval starts, separated by a defined Duration. If the Duration is absent, then the Referenced Interval will start at the same time that the Originating Interval starts. A negative Duration specifies that the Referenced Interval starts before the Originating Interval..

If a specification that claims conformance this specification permits a missing temporalRelation, then that 324 specification MUST state which Temporal Relation is implied. A conforming specification MAY disallow a 325 missing temporalRelation. 326

4.2.2 Sequences 327

Sequences are collections of Intervals connected by Temporal Relationships. There is no Sequence 328 structure per-se. A Sequence is referenced by referencing the InstanceUID of one Interval in the 329 Sequence. That Interval is referred to as the Designated Interval. The Designated Interval has special 330 rules for Inheritance. For example, when a Gluon Bequeaths a dtStart to a Sequence, is it the Designated 331 Interval that starts at that time. 332

Inheritance within a Sequence is specified in the [PIM]. 333

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 18 of 26

4.3 The Gluon 334

The Gluon links a Sequence to a service interaction. The Gluon can be considered a degenerate Interval 335 that cannot itself be executed. It does, however provide missing information to fully bind each Interval in 336 the Sequence. 337

Another perspective describes the Gluon as the service entry point for an activity defined by a Sequence. 338 Sequence execution is launched by providing a dtStart though a Gluon. A service request acting as a 339 Gluon bequeaths missing information that is inherited by the entry point Gluon to bind the Sequence. 340

The Gluon Type is shown in Figure 4-3: The Gluon. 341

342

Figure 4-3: The Gluon 343

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 19 of 26

Notice that the Gluon is nearly identical to the Interval. A Requested Start replaces the dtStart. Requested 344 Start is of type Recurrence. Recurrence describes how to compute a collection of dtStarts. Recurrence is 345 discussed in below in Section 5. 346

The significant changes are as follows: 347

1) The Gluon has no Temporal Links. It cannot be part of a Sequence, so it maintains not Temporal 348 Relations with other Components. 349

2) A Gluon must have at least one Relation, and it can have many. The Relation connects a Gluon 350 to a Sequence, to establish Inheritance. A Relation MAY connect a Gluon to another Gluon, 351 establishing a Lineage that eventually binds a Sequence. 352

3) A Gluon may convey multiple dtStarts.This collection is computed in RequestedStart, which is of 353 type Recurrence. A recurrence is a structure to convey or compute a collection of starting dates 354 and times. These act as if there were multiple Gluons, each conveying a single dtStart. 355

4) vAvaialbility. VAvailability is an outward looking element that conveys information about potential 356 schedules for the underlying Sequence. 357

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 20 of 26

5 Enhancing Service Advertising and Request: 358

Recurrence and Availability 359

Up until this section, dates and times were specific. This section introduces Recurrence and types that 360 enable patterns of dates and schedules to be computed. 361

These computable schedules expand the capability of a Gluon. 362

Table 5-1: Computable Schedules: Availability and Gluon 363

Service Types Description

Recurrence Conceptually, the last thing specified to Fully Bind a Sequence is When, i.e., the start date and time. Recurrence is an information structure that enables the computation of a collection of starting dates and times.

Recurrence Rule

Recurrence rules define periodic repletion of times and dates. The language of Recurrence is well known as defined in [RFC5545] section 3.3.10.

VAvailability VAvailability is an optional component of a Gluon that is not inherited, but rather specifies when the underlying Sequence may be invoked

Availability Availability is a component of VAvailability, and presents as a single instance of a Recurrence Rule applied to an Interval with Duration.

Availability Interval

An Interval (Duration and Start) used as a seed for recurrence within an Availalbility component

Time Range An Interval (Duration and Start) used to bound VAvailability.

Busy Type Used to indicate whether the schedule in a vAvailaibility is Free, Busy (unavailable), or tentatively busy.

There may be good reasons for a specification that claims conformance with this specification to forbid e 364 Recurrence. Requiring each service invocation to require its own message that acts as a Gluon MAY 365 simplify the system. A conforming specification MUST state of the use of these components is forbidden. 366

5.1 Recurrence Rules 367

Recurrence Rules are used in both Recurrence and in Availability to compute patterns of schedules and 368 dates. Each Rule consists of a Rule Part, which names a type of Rule, and Rule Values, constrained lists 369 which operate within the Rule Part. 370

371

Figure 5-1: The Recurrence Rule 372

Representative recurRuleParts indicate that a Rule is hourly, or at a fixed frequency, or on certain days of 373 the month. Rule Values are constrained depending on the RulePart, to indicate days of the week, every 374 three hours, and so on. 375

Recurrence Rules are normatively described in [RFC5545] section 3.3.10. Many web-sites and open 376

source libraries discuss these rules; no efforts will be made in this specification to re-state these rules. 377

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 21 of 26

5.2 Recurrence 378

Recurrence is conveys a mechanism to compute a collection of starting date-times. At its simplest, it is a 379 dtStart, just as in the Interval. Recurrence Rules then describe how to compute additional starting dates 380 and times using the dtStart as a seed. rDates add additional starting dates to the collection. xDates then 381 block out dates,that is, remove specific dat-times from the collection. 382

383

Figure 5-2: Recurrence 384

The Requested Start in the Gluon is of type Recurrence. 385

5.3 Availability and VAvailability 386

VAvailability is the sum of one or more patterns (Availability) that together express when a Service can be 387 invoked. 388

As a non-normative illustration, the well-known pattern of “During Business Hours” can be described as 389 the hours from 9:00 AM to 5:00 PM repeated weekly on Monday, Tuesday, Wednesday, Thursday, and 390 Friday. Alternately is might be the sum of two patterns, 8:00 AM until noon, Monday, Tuesday, 391 Wednesday, Thursday, and Friday and 1:00 until 5:00 on Monday, Tuesday, Wednesday, Thursday, and 392 Friday. An additional pattern of 9:00 AM until 1:00 PM might be added each Saturday. The smaller 393 patterns are named “Availability” and the top level summary is named VAvailability. 394

Note that a Gluon may have an array of Vavailability components. These components MAY be both 395 Avaiiable and Unavailable in the same set. There are specific rules for overlaying vAvailability 396 components which the practitioner should be aware of. These rules are described in [vAvailability]. 397

5.3.1 Availability 398

The Availability type uses the same computational rules as Reccurrence and applies then to a seed 399 Interval, that is a Duration and dtStart. The DateTime and the Duration are known as the Availability 400 Interval. 401

402

403

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 22 of 26

404

Figure 5-3: Availability 405

Availability applies the Recurrence Rules (RRules) defined in [RFC5545] to the availability interval. 406

5.3.2 VAvailability 407

VAvailability represents the sum of a collection of Availability types applied within the bounds of a defined 408 Time Range. 409

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 23 of 26

410

Figure 5-4: VAvailability Type 411

Note that Granularity, when applied to vAvailability has a special meaning. A three hour interval 412 advertised with a granularity of 15 minutes may only be invoked an the 15 minute interval. Forexample, 413 the interval may be 9:00 until Noon, but the only dtStarts that may be requested are at 9:00, 9:15, 8:30, 414 9:25 and so on, 415

416

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 24 of 26

6 Conformance 417

6.1 Conformance with the Semantic Models of WS-Calendar-PIM 418

This section specifies conformance with the semantic models of [WS-Calendar-PIM]. This specification 419 requires that specifications claiming conformance also conform to the specific conformance requirements 420 of [WS-Calendar-PIM] are described in section 5.3 of that specification, “Conformance Rules for WS-421 Calendar PIM”. 422

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 25 of 26

Appendix A. Acknowledgments 423

The following individuals have participated in the creation of this specification and are gratefully 424 acknowledged: 425

Participants: 426 David Thewlis, CalConnect 427 William Cox, Individual 428 Gershon Janssen, Individual 429 Benoit Lepeuple, LonMark International 430 Michael Douglass, Rensselaer Polytechnic Institute 431 Toby Considine, University of North Carolina at Chapel Hill 432 Chris Bogen, US Department of Defense (DoD) 433 434

ws-calendar-min-wd02 Working Draft 02 July 22, 2015 Standards Track Draft Copyright © OASIS Open 2013-2015. All Rights Reserved. Page 26 of 26

Appendix B. Revision History 435

436

Revision Date Editor Changes Made

WD01 21-Jul-2015 Toby Considine Initial Draft

WD02 22-Jul-2015 Toby Considine Added section on Recurrence and Availability. Added recurrence to Gluons.

437

438