WS-Calendar Platform Independent Model (PIM) Version 1.0
Working Draft 07
17 January 2014
Technical Committee:
OASIS Web Services Calendar (WS-Calendar) TC
Chair:
Toby Considine ([email protected]), University of North Carolina at Chapel Hill
Editors:
William Cox ([email protected]), Individual
Toby Considine ([email protected]), University of North Carolina at Chapel Hill
Additional artifacts:
This prose specification is one component of a Work Product, which also includes:
 XMI Documents representing the UML model described in the specification
Related work:
This specification is related to:

WS-Calendar Version 1.0. Latest version.
http://docs.oasis-open.org/ws-calendar/ws-calendar/v1.0/ws-calendar-1.0-spec.html
Declared XML namespace:
 There are no XML namespaces declared in this specification
Abstract:
The Platform Independent Model is an abstract model that defines conformance and improves
interoperation of calendar and schedule models with each other and with WS-Calendar and Xcal,
which are in turn based on IETF RFCs.
This is a Platform Independent Model under the Object Management Group’s Model-Driven
Architecture. The Platform Dependent Model to which this specification relates is the full model
for WS-Calendar as expressed in XML (xCal).
The focus of this Platform Independent Model is on describing and passing schedule and interval
information with information attachments.
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 reapprove it any number of times as a Committee Draft.
Copyright © OASIS Open 2012-2014. 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,
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.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 1 of 37
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-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 2 of 37
Table of Contents
1
Introduction ............................................................................................................................................. 6
1.1 Terminology ........................................................................................................................................ 6
1.2 Normative References ........................................................................................................................ 6
1.3 Non-Normative References ................................................................................................................ 6
1.4 Namespace ......................................................................................................................................... 7
1.5 Naming Conventions .......................................................................................................................... 7
1.6 Editing Conventions ............................................................................................................................ 7
1.7 Architectural References and Background ......................................................................................... 7
2 Architecture ............................................................................................................................................. 8
2.1 The PIM and the WS-Calendar PSM .................................................................................................. 8
2.2 Key Abstractions ................................................................................................................................. 8
2.3 Expression of the PIM ......................................................................................................................... 8
2.4 Structure of the PIM Model and Specification .................................................................................... 9
2.5 Expression in UML .............................................................................................................................. 9
3 Detailed Terminology and Semantics ................................................................................................... 10
3.1 Semantics in WS-Calendar and the WS-Calendar PIM ................................................................... 10
3.2 Semantics ......................................................................................................................................... 10
4 The Platform-Independent Model ......................................................................................................... 14
4.1 Introduction to the PIM ...................................................................................................................... 14
4.1.1 Model Diagram of the PIM ......................................................................................................... 15
4.1.2 Discussion ................................................................................................................................. 16
4.2 Primitive Types ................................................................................................................................. 16
4.2.1 Introduction ................................................................................................................................ 16
4.2.2 Model Diagram .......................................................................................................................... 17
4.2.3 Discussion ................................................................................................................................. 17
4.2.4 Relationship to other PIM Components .................................................................................... 17
4.3 Interval .............................................................................................................................................. 18
4.3.1 Introduction ................................................................................................................................ 18
4.3.2 Model Diagram .......................................................................................................................... 18
4.3.3 Discussion ................................................................................................................................. 18
4.3.4 Relationship to other PIM Components .................................................................................... 19
4.4 Payload Attachment to an Interval .................................................................................................... 19
4.4.1 Introduction ................................................................................................................................ 19
4.4.2 Model Diagram .......................................................................................................................... 19
4.4.3 Discussion ................................................................................................................................. 19
4.4.4 Relationship to other PIM Components .................................................................................... 20
4.5 Relationships .................................................................................................................................... 20
4.5.1 Introduction ................................................................................................................................ 20
4.5.2 Model Diagram .......................................................................................................................... 21
4.5.3 Discussion ................................................................................................................................. 21
4.5.4 Relationship to other PIM Components .................................................................................... 21
4.6 Gluons ............................................................................................................................................... 22
4.6.1 Introduction ................................................................................................................................ 22
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 3 of 37
5
6
7
8
4.6.2 Model Diagram .......................................................................................................................... 22
4.6.3 Discussion ................................................................................................................................. 23
4.6.4 Relationship to other PIM Components .................................................................................... 23
4.7 Tolerance and Duration .................................................................................................................... 23
4.7.1 Introduction ................................................................................................................................ 23
4.7.2 Model Diagram .......................................................................................................................... 23
4.7.3 Discussion ................................................................................................................................. 23
4.7.4 Relationship to other PIM Components .................................................................................... 23
4.8 Availability ......................................................................................................................................... 24
4.8.1 Introduction ................................................................................................................................ 24
4.8.2 Model Diagram .......................................................................................................................... 24
4.8.3 Discussion ................................................................................................................................. 24
4.8.4 Relationship to other PIM Components .................................................................................... 24
Examples using the PIM ....................................................................................................................... 25
5.1 Introduction ....................................................................................................................................... 25
5.2 A Meeting Schedule .......................................................................................................................... 25
5.3 An Energy Schedule ......................................................................................................................... 26
5.4 Academic Scheduling Example ........................................................................................................ 26
5.5 Further Examples from WS-Calendar .............................................................................................. 26
5.6 Architectural Approaches.................................................................................................................. 27
PIM to WS-Calendar PSM Transformation ........................................................................................... 28
6.1 General Transformation .................................................................................................................... 28
6.2 Specific Transformations .................................................................................................................. 28
PIM to IEC TC57 CIM Intervals and Sequences .................................................................................. 29
Conformance and Rules for WS-Calendar PIM and Referencing Specifications ................................. 30
8.1 Introduction ....................................................................................................................................... 30
8.2 Relationship to WS-Calendar CS01 [Non-Normative] ...................................................................... 30
8.3 Conformance Rules for WS-Calendar PIM....................................................................................... 30
8.3.1 Inheritance in WS-Calendar ...................................................................................................... 30
8.3.2 Specific Attribute Inheritance ..................................................................................................... 31
8.3.3 General Conformance Issues .................................................................................................... 31
8.3.4 Covarying Elements .................................................................................................................. 31
8.3.5 Conformance of Intervals .......................................................................................................... 32
8.3.5.1 Intervals ............................................................................................................................................. 32
8.3.5.2 Other Elements .................................................................................................................................. 32
8.3.6 Conformance of Bound Intervals and Sequences..................................................................... 32
8.4 Conformance Rules for Specifications Claiming Conformance to WS-Calendar PIM ..................... 32
8.5 Security Considerations .................................................................................................................... 32
Appendix A. Acknowledgments ............................................................................................................... 34
Appendix B. Revision History .................................................................................................................. 35
Appendix C. PIM and WS-Calendar Semantics Differences ................................................................... 36
Appendix D. PIM and WS-Calendar Conformance Differences .............................................................. 37
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 4 of 37
Table of Figures
Figure 4-1 The Complete WS-Calendar PIM UML Model .......................................................................... 15
Figure 4-2 Primitive Types .......................................................................................................................... 17
Figure 4-3 The PIM IntervalType ................................................................................................................ 18
Figure 4-4 Attaching a Payload to an Interval ............................................................................................. 19
Figure 4-5 Relation Link Type and Relationship Types .............................................................................. 21
Figure 4-6 Gluons and their Relationship to Intervals. Note cardinality of relation associations ................ 22
Figure 4-7 Duration and Tolerance ............................................................................................................. 23
Figure 4-8 Vavailability and Availability Recurrence Rules ......................................................................... 24
Figure 5-1 Simple Meeting Schedule .......................................................................................................... 26
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 5 of 37
1
1 Introduction
2
All text is normative unless otherwise labeled.
3
1.1 Terminology
4
5
6
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].
7
1.2 Normative References
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[ISO8601]
[RFC3986]
[RFC2119]
[RFC5545]
[WS-Calendar]
[xCal]
[XMI]
ISO (International Organization for Standardization). Representations of dates
and times, third edition, December 2004, (ISO 8601:2004)
T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifier (URI):
Generic Syntax, http://www.ietf.org/rfc/rfc3986.txt, IETF RFC 3986, January
2005.
S. Bradner, Key words for use in RFCs to Indicate Requirement Levels,
http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
B. Desruisseaux Internet Calendaring and Scheduling Core Object Specification
(iCalendar), http://www.ietf.org/rfc/rfc5545.txt, IETF RFC5545, proposed
standard, September 2009
WS-Calendar Version 1.0, 30 July 2011, OASIS Committee Specification.
http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/cs01/ws-calendarspec-v1.0-cs01.html (PDF is authoritative)
C. Daboo, M Douglass, S Lees, xCal: The XML format for iCalendar,
http://tools.ietf.org/html/rfc6321, IETF RFC 6321, August 2011.
XMI Version 2.1, September 2005, Object Management Group,
http://www.omg.org/spec/XMI/2.1/ 1
1.3 Non-Normative References
26
27
28
29
30
31
32
33
[EnergyInteroperation]
OASIS Energy Interoperation 1.0, OASIS Committee Specification 02, 18
February 2012, http://docs.oasis-open.org/energyinterop/ei/v1.0/energyinteropv1.0.html
[IANA]
The Internet Assigned Numbers Authority, http://www.iana.org.
[MDA-Overview] The Architecture of Choice for a Changing World, Object Management Group,
http://www.omg.org/mda/
[MDA]
OMG Model Driven Architecture Specifications, Object Management Group,
http://www.omg.org/mda/specs.htm
1
The version of XMI as of this Working Draft is 2.4.1, but the tools used for UML support version 2.1.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 6 of 37
34
35
36
37
38
39
[Vavailability]
40
1.4 Namespace
41
There are no XML namespaces defined in this specification.
42
1.5 Naming Conventions
43
This specification follows a set of naming conventions for artifacts defined by the specification, as follows:
44
45
For the names of attributes in UML definitions the names follow the lower camelCase convention, with all
names starting with a lower case letter. For example, an attribute name might be
46
47
48
49
C. Daboo, B. Douglass, Calendar Availability, http://tools.ietf.org/html/draftdaboo-calendar-availability-03, IETF Internet Draft Version 03, September 27,
2012
[UML]
Unified Modeling Language, Object Management Group, http://uml.org/
[EnterpriseArchitect]
Sparx Enterprise Architect 9.3 and 10.0, used to produce diagrams, EAP
and [XMI] version 2.1 files
component
The names of UML classes, the names follow the upper CamelCase convention with all names starting
with an Upper case letter followed by “Type“.
component: ComponentType
50
1.6 Editing Conventions
51
52
For readability, UML attribute names in tables appear as separate words. The actual names are
lowerCamelCase, as specified above, and do not contain spaces.
53
All items in the tables not marked as “optional” are mandatory.
54
55
Information in the “Specification” column of the tables is normative. Information appearing in the “Note”
column is explanatory and non-normative.
56
All sections explicitly noted as examples are informational and are not to be considered normative.
57
1.7 Architectural References and Background
58
59
60
61
WS-Calendar and this WS-Calendar PIM assume incorporation into services. Accordingly it assumes a
certain amount of definitions and discussion 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].
62
63
64
65
66
Service-Oriented Architecture comprises not only the services and interaction patterns, but also the
information models that support those services and make the actions meaningful. The WS-Calendar PIM
is such an information model for expressing schedule and time related information in a consistent manner
and to permit easy transformation or adaptation into IETF iCalendar related specifications and among
implementations.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 7 of 37
67
2 Architecture
68
69
The Object Management Group’s Model Driven Architecture [MDA-Overview][MDA] is a way of
describing relationships between Unified Modeling Language [UML] models.
70
An instance of MDA has two classes of models:
71
72


A single Platform-Independent Model, abbreviated PIM
One or more Platform-Specific Models, abbreviated PSM (pronounced as though spelled pism)
73
74
The more abstract PIM typically captures the more abstract relationships, making the architecture more
clear. The PSM is bound to a particular platform.
75
76
77
78
The art of establishing an instance of MDA includes defining a PIM and PSMs, which solve interesting
and important and useful problems. Artifacts expressed in different PSMs may more readily be
exchanged and understood with reference to the related PIM, making interoperation simpler and
semantics more free from irrelevant detail.
79
2.1 The PIM and the WS-Calendar PSM
80
81
82
In this specification we define a PIM or Platform-Independent Model for the [WS-Calendar] extensions to
IETF [iCalendar][xCAL] and the relevant types included in [xCAL]. We use “the PIM” meaning exactly
“the WS-Calendar PIM” through this specification.
83
84
85
86
[iCalendar] uses a specific platform, developed over time, to express relationships, times, events, and
availability. As such, the expression is very simple, but in the aggregate relatively complex and less
suitable to UML expression—the several key types have sets of values and attributes associated with
them in a relatively flat hierarchy.
87
88
89
90
91
This PIM addresses the key abstractions as defined in [WS-Calendar] in a manner that allows for
understanding the nature and information model for those abstractions. In effect, we are creating a PIM
with respect to which the WS-Calendar specification is a PSM. Our purpose is to create a more abstract
model of the key concepts in WS-Calendar for easier use in application development, standardization,
and interoperation.
92
93
This specification does not depend on any specific MDA tooling or environments to be useful. In a
subsequent section we describe a transformation from the PIM to [WS-Calendar].
94
2.2 Key Abstractions
95
We define the following in order:
96
97
98
99
100
101
102







Primitive Types for date, time, and duration
The Interval
Payload attachment to an Interval
Relations
The Gluon
Tolerance
Availability
103
2.3 Expression of the PIM
104
105
106
The PIM is a [UML] model. We represent the PIM as a normative [XMI] serialization of the model. The
model is described using [Enterprise Architect]. The Enterprise Architect Project file is part of this work
product but is non-normative.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 8 of 37
107
2.4 Structure of the PIM Model and Specification
108
109
110
111
112
The PIM consists of a small number of key concepts and constructs as listed in Section 2.2. These are
expressed in a largely flat structure, with a sub-package only for the Availability abstractions. 2 We have
not used UML packages for the core abstractions, but expect (See Section 8) that conforming
specifications and implementations MAY claim conformance to sub-parts of the PIM, e.g. to only the
Interval.
113
114
115
We encourage consideration and use of the entire PIM, but understand that some aspects of the abstract
model may be more complex than needed to address specific problems. We consider such profiles of the
PIM to (notwithstanding the discussion on complexity and PSMs above) be a Platform-Specific Model.
116
117
118
119
We take the exact names for abstractions in the PIM from the names in [WS-Calendar] to simplify
implementations and mappings where needed to bridge to a specific implementation conforming to [WSCalendar]. We exercise care to disambiguate terms where there are multiple fully qualified terms of the
same end component name.
120
121
122
Many attribute values in [xCAL] are conformed strings in XML, that is, strings with certain defined
patterns. We require those same standardized formats for conformed strings, and record the type in this
PIM as string to allow easy transformation between this PIM and the PSMs.
123
2.5 Expression in UML
124
125
126
127
There are constraints and semantic rules and conformance that apply to a UML model defining the WSCalendar PIM. However, the UML cardinality expressions and constraints give a flexibility of expression,
and allow for determining values in fully bound class instances that are less succinct than the
standardized expressions.
128
129
130
131
For example, an instance of Interval (see Figure 4-3 The PIM IntervalType) might have only a duration;
the UML, however, lists duration as optional (cardinality 0..1). Rules in this specification show how a
specific representation is to be interpreted, typically by inheriting values from elsewhere. Conceptually,
the actual values depend the context.
132
133
134
135
An Interval notionally has a start time, but that also is optional in the UML model. Finally, an Interval does
not have an end time (expressed in Figure 4-3 as dtEnd of cardinality 0. We keep the dtEnd for ease of
use in PSMs and for intermediate stages of mapping into the canonical start and duration model, as well
as mapping into and from models that define intervals with all three of start, end, and duration.
136
137
138
139
140
141
142
These characteristics are as defined in [WS-Calendar] and describe an abstract Interval with at most a
start time and duration. This is in contrast to some historical models that require each interval to contain a
start and end time, or occasionally start, end, and duration. The added flexibility of relocatable sets or
schedules comprised of Intervals and Gluons, makes the expression of such a schedule easy and
reusable, thus permitting a powerful abstraction to be applied to all sorts of scheduling expressions. In
addition the mapping capability to and from the PIM allows interoperation with systems with less
conveniently relocatable intervals.
2
The Vavailability definition is in process in the IETF.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 9 of 37
143
3 Detailed Terminology and Semantics
144
3.1 Semantics in WS-Calendar and the WS-Calendar PIM
145
146
147
WS-Calendar PIM semantics are nearly identical to those defined in Section 1.9 of [WS-Calendar]. The
minor differences between the referenced section and those in Section 3.2 below are listed in a nonnormative Appendix.
148
149
150
151
This specification and [WS-Calendar] share the same semantics and terminology, which allows easier
exchange of information across execution environments as well as consistency across Platform Specific
Models related to this specification. In addition, the definition of conformed strings for representation of
duration and date and time per [ISO8601] is identical.
152
153
154
[WS-Calendar] defines XML and XML Schema artifacts; the terminology differs from UML, most
obviously in that XML distinguishes between elements and attributes within a type, while UML uniformly
uses the term attributes.
155
3.2 Semantics
156
157
158
159
Certain terms appear throughout this document, some with extensive definitions. Table 3-1 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.
160
161
162
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 3-1 through Table 3-4 below, and are
quoted from [WS-Calendar]. The definitions are normative because this is a standalone specification.
163
Table 3-1: 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.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 10 of 37
Time Segment
164
165
166
167
168
Definition
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 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 information attached to, and presumably that occurs or is
relevant to the time span described by an Interval. WS-Calendar uses the
Artifact as a placeholder. The contents of the Artifact are not specified in WSCalendar; rather the Artifact provides an extension base for the use of WSCalendar 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 3-2.
169
Table 3-2: 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 Availability. Busy can be Inherited.
Child, Children
The CHILD relationship type (RelationshipType) 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
(RelationshipType) 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-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 11 of 37
170
171
172
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 3-3 defines the
terms used to describe inheritance.
173
Table 3-3: 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.
174
175
176
177
178
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 3-4 defines the terms used when discussing
the processing or processability of Intervals and Sequences.
179
180
181
182
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
3-4 defines the language used to discuss how the information in an Interval is completed.
183
Table 3-4: 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 nor 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.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 12 of 37
Term
Definition
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.
184
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 13 of 37
185
4 The Platform-Independent Model
186
187
188
In this section we first introduce the PIM, and then treat in turn each component of the PIM. Each
subsection has an introduction, a diagram, and discussion that may include the relationship of the
respective components to the rest of the PIM.
189
190
This Platform-Independent Model (PIM) [MDA] describes an abstraction from which the Platform-Specific
Model (PSM) of [WS-Calendar] can be derived. The intent is twofold:
191
192
193
194
(1) To define an abstraction for calendar and schedule more in the style of web services descriptions,
and
(2) To define the PIM as a model allowing easy transformation or adaptation between systems using
the family of WS-Calendar specification.
195
4.1 Introduction to the PIM
196
197
In this section we present the entire PIM together with architectural discussion. The following sections
begin with a description of the full model, and then address
198
199
200
201
202
203
204







Primitive types
The Interval
Payload attachment an Interval
Relations
The Gluon,
Tolerance, and
Availability
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 14 of 37
205
4.1.1 Model Diagram of the PIM
206
207
Figure 4-1 The Complete WS-Calendar PIM UML Model
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 15 of 37
208
4.1.2 Discussion
209
210
Primitive types express fundamental information related to date, time, and duration, and follow
[RFC5545] [ISO8601] and are a superset of those expressed in [iCalendar].3
211
212
213
Associations in the PIM are directional, but profiles and PSMs derived or derivable from the PIM may
have non-directional associations, vary the direction of associations to fit their particular platform(s) and
purposes.4
214
215
Attributes and associations’ cardinality is defined in the PIM; profiles and PSMs derived or derivable from
the PIM may have different cardinality.
216
Attachments are made via the abstract class AttachType as described in Section 4.4.
217
218
We have used the [RFC5545] [ISO8601] [iCalendar] attribute names wherever possible for ease of
mapping to that common terminology. In particular, a fully bound Interval is defined by two of



219
220
221
dtStart—the date & time [dt] for the start of the Interval
dtEnd—the date & time for the end of the Interval
duration—the duration (expressed as in [ISO8601]) for the Interval
222
223
224
225
226
For UML model purposes, the three key values for an interval, only two of which are required in fully
bound Intervals, are each optional. This permits a conforming instantiation to have zero or more of the
three key values; the semantics of Gluons and Intervals in Section 3.2 describe how information for a
bound interval is determined. Note also that GluonType while a subclass of IntervalType has a more
restrictive cardinality for dtEnd and for relation.
227
4.2 Primitive Types
228
4.2.1 Introduction
229
In this section we introduce key concepts and expressions for time including




230
231
232
233
234
DateTime
Duration
DurationValueType
ToleranceValueType
Relationships are described in Section 4.5.
3
See discussion in Section 4.2 which includes relationship to [XSD] DateTime types.
Note that non-directional associations are a barrier to serializability in messages; hence all PSMs typically would
use directional associations unless their purpose is to derive further PSMs.
4
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 16 of 37
235
4.2.2 Model Diagram
236
237
Figure 4-2 Primitive Types
238
239
All durations are expressed as conformed strings, that is, the type is string and the content of the string
determines the duration.
240
241
The values of the following SHALL be expressed as conformed strings as described in the normative
reference [RFC5545]:


242
243
DateTime (See Section 3.3.5, Date-Time, in [RFC5545])
DurationValueType (See Section 3.3.6, Duration, in [RFC5545])
244
245
Both DateTime and DurationValueType SHALL permit the full set of [ISO8601] date & time and duration
conformed strings.
246
The class

247
ToleranceValueType
248
Is comprised of a set of optional attributes of DurationValueType and is defined in this specification.
249
4.2.3 Discussion
250
251
252
These concepts are based on [ISO8601] and are as expressed in [iCalendar] as conformed strings. It is
important to note that DurationValueType is not the same as that in XML Schema Specification [XSD]
Duration.5
253
4.2.4 Relationship to other PIM Components
254
255
256
These concepts are pervasive in the WS-Calendar PIM. The fundamental understanding of time and
duration must be consistent and identical to that in [iCalendar] for clean interoperation and
transformation. Documentation of any differences in expression MUST be included in the conformance
5
While [iCalendar], [WS-Calendar], and this WS-Calendar PIM share the same conforming values, and conform to
[ISO8601], [XSD] does not include the full specification in [ISO8601]. In fact, there are duration strings included in
[XSD] that are not in [iCalendar] and vice versa.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 17 of 37
257
258
statement for any PSM claiming conformance to this PIM. Moreover, a mapping MUST be provided both
directions between the types defined here and those in a PSM claiming conformance.
259
4.3 Interval
260
4.3.1 Introduction
261
262
The Interval seems to be a simple concept—a bound interval starts at a particular time, runs for a specific
duration, and ends at a particular time. This is reflected in Figure 4-3.
263
4.3.2 Model Diagram
264
265
Figure 4-3 The PIM IntervalType
266
267
4.3.3 Discussion
268
269
270
271
272
The IntervalType class is the fundamental unit for expressing a time interval; while logically any two or
three of the set {dtStart, dtEnd, and duration} can express an interval, there are significant advantages to
adopting a single canonical form, particularly one where the semantics are cleanly expressed. Intervals
may be, and are, expressed many ways. The PIM requires a specific expression to include start time and
duration but not end time.6
273
274
Following [WS-Calendar], the canonical PSM that can be managed by standard iCalendar servers, we
choose dtStart and duration.
275
276
277
278
Individual PSMs may use different expressions, but SHOULD recognize in their design that relocation and
scheduling of sets of intervals is a very common operation; as we will show later, an entire schedule of
Intervals in this WS-Calendar PIM can be scheduled with a single operation, whereas in other
representations each dtStart and dtEnd might have to be modified when scheduling.
279
See also Section 2.5.
6
See [ISO8601] section 4.4.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 18 of 37
280
4.3.4 Relationship to other PIM Components
281
282
The IntervalType class is fundamental to expression of time interval, as are duration and dateTime. Most
semantics are with respect to determining values for bound and unbound Intervals.
283
Payload values are attached to an Interval, as described in the next section.
284
4.4 Payload Attachment to an Interval
285
4.4.1 Introduction
286
287
As in [WS-Calendar] a payload, which may be comprised of multiple subparts, is attached to an Interval.
This differs from
288
289
290
(a) A value containing a description of an Interval (e.g. a measurement that applies to an included
Interval)
(b) Associating an interval to a particular measurement (the association is the wrong direction)
291
The association is directional, and must be completed for use of the Interval instance.
292
4.4.2 Model Diagram
293
294
Figure 4-4 Attaching a Payload to an Interval
295
4.4.3 Discussion
296
297
298
299
[WS-Calendar] (line 219) requires that the Attachment Payload and Start Duration must be complete for
service performance. In this specification we have defined the cardinality of attach to be 0..1 to allow for
abstract schedules, including those to which payloads are bound before service performance or concrete
use.
300
301
A PSM claiming conformance to this PIM MAY change and document any changes in cardinality or
direction of associations in its conformance statement.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 19 of 37
302
4.4.4 Relationship to other PIM Components
303
304
305
The IntervalType is fundamental; application information is attached to instances of the IntervalType by a
clear, directional association. This maintains the temporal structure of schedules with a variety of
attachments.
306
4.5 Relationships
307
4.5.1 Introduction
308
309
310
311
312
Relationships between instances of IntervalType are accomplished with RelationLinks. In [WS-Calendar]
the LinkType is defined flexibly to be a UID (as defined in [xCal]), a URI [RFC3986], or a reference string.
This supports both distributed schedules and local identifiers that need not be fully qualified as would be a
UID or a URI. In the PIM, we use a string which may contain a useful reference, without defining the
precise type or uses of that reference—that is left to the PSMs.
313
314
315
The TemporalRelationshipType and gap together determine the relationship of the referencing Interval
and referenced Interval instances. The gap is a pure ISO8601 duration, considered as a signed offset; the
TemporalRelationshipType express the kind of relationship:

316
317
318
319
320
321
322
323
324



FinishToStart (the conventional, the referenced interval is after the Finish of the referencing
Interval, with an optional gap)
FinishToFinish (the end of the referencing Interval aligns with the end of the referenced Interval,
with an optional gap)
StartToFinish (the start of the referencing Interval aligns with the end of the referenced Interval,
with an optional gap)
StartToStart (the start of the referencing Interval aligns with the start of the referenced Interval,
with an optional gap.
Finally, the RelationshipType expresses whether the relationship is PARENT, CHILD, or SIBLING.7
7
[WS-Calendar] and [xCal], as with many other IETF RFCs,, also include as enumberatino values an extension
point (x-name) and an IANA-registered xCal token (iana-token) [IANA]. These are not part of the PIM.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 20 of 37
325
4.5.2 Model Diagram
326
327
Figure 4-5 Relation Link Type and Relationship Types
328
4.5.3 Discussion
329
330
The PIM (and WS-Calendar) supports the common relationships between time intervals, as expressed in
schedules, project management tools, and business process definitions such as BPEL and BPMN.
331
332
333
The relationships are expressed using the temporal relationship, the temporal gap between intervals, and
the kind of relationship between Gluons and Intervals expressed as Parent, Child, and Sibling. Gluons are
discussed in the next section.
334
335
The set is logically complete, and allows complex structures to be built from primitive relationships,
passed in service invocations, and interpreted correctly.
336
337
338
339
In contrast with the WS-Calendar PSM, LinkType contains only a single string. The broader range of links
in the WS-Calendar PSM includes a UID, a URI, or other kind of reference (implementation-defined).
Since the abstract link is conceptually a pointer in the PIM, we define a single reference there. It is
maintained as a class to allow the diversity of PSM definitions including that of [WS-Calendar].
340
341
342
A PSM claiming conformance to the PIM SHALL document how it manages and maintains links. In
particular, the conformance statement SHALL include a description of uniqueness of references in that
PSM.
343
4.5.4 Relationship to other PIM Components
344
345
346
The use of relation allows all of the common relationships between time intervals to be expressed with
optional offsets (the optional Gap), while abstracting the details of the relationship into the
RelationLinkType class.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 21 of 37
347
4.6 Gluons
348
4.6.1 Introduction
349
350
351
The Gluon is a new concept in [WS-Calendar]. It may be thought of as a simple reference to a sequence
(a set of temporally-related intervals), but while its structure is that of an interval it is functionally a pointer
into a sequence.
352
353
354
A sequence may be referenced by many different gluons; the view of a sequence is determined by the
referencing gluon and values that may be inherited from the referencing gluon such as start time and
durations.
355
356
357
358
More formally, a Gluon references schedules comprised of related Intervals and Gluons, while providing a
place for logical information such as the duration of Interval instances so that information may be
inherited by referenced Interval instances. The structure permits directed graphs of instances with reuse
of components. Those subgraphs may therefore act as reusable sub-schedules.
359
360
361
362
363
The Gluon may be thought of as a reference into a graph of Intervals or Gluons, allowing differing
schedule views depending on the starting point. For example, a room schedule that includes room
preparation, meetings, and room cleanup could have a gluon pointing to the preparation Interval for those
interested in the preparation starting point and associated actions, and another Gluon pointing to the start
of the meetings.
364
365
GluonType is a subclass of IntervalType with the added requirement that there be at least one
RelationLink; IntervalType has zero or more associated RelationLinks.
366
367
A gap is signed, so a gap of P-1H for a related interval with TemporalRelationshipType of StartToFinish
would mean that the referenced interval starts one hour before the referring interval.
368
369
These relationships may be used to compose arbitrarily complex graphs of instances of Intervals and
Gluons.
370
4.6.2 Model Diagram
371
372
Figure 4-6 Gluons and their Relationship to Intervals. Note cardinality of relation associations
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 22 of 37
373
4.6.3 Discussion
374
375
376
377
Gluons look and act very much like Intervals. One could think of the Gluon as an optional container for
values to “fill in” Interval attributes dynamically and depending on the relationships among the instances.
This technique is used in [EMIX] and [EnergyInteroperation] to build energy schedules with varying
values but consistent lengths.
378
4.6.4 Relationship to other PIM Components
379
380
See the detailed discussion of Semantics in Section 3.2. Gluons contain values that may be inherited or
overridden in its children.
381
4.7 Tolerance and Duration
382
4.7.1 Introduction
383
384
385
No timing of events, whether descriptive or prescriptive, can be perfectly accurate within the limits of
measurement of real systems. The ToleranceValueType is an optional attribute of DurationValueType,
allowing full flexibility in the description of permissible or expected variation in duration. See Figure 4-7.
386
387
The related interval may start early or late, end early or late, or have a duration that may be short or long
with respect to the nominal value in howlong. The precision used to describe tolerance is also included.
388
4.7.2 Model Diagram
389
390
Figure 4-7 Duration and Tolerance
391
4.7.3 Discussion
392
393
The nature of duration includes a degree and the specification of tolerance with respect to start time, end
time, and duration. Tolerances can be expressed in any combination.
394
395
396
397
The use of tolerances can allow (e.g.) randomization of intervals to ensure that certain activities do not
occur “simultaneously.” For example, a startbefore of 5s and startafter of 10s indicates that the actual
start time may be in the range from 5s before to 10s after the indicated dtStart. Additional deployment
semantics for randomization may use this same expressed range.
398
4.7.4 Relationship to other PIM Components
399
Any duration, start, or end time as stated (or computed when bound) is subject to tolerance.
400
401
DurationValueType is the xCal conformed string but is missing some ISO8601 values. This conformed
string type is therefore called "DurationStringType" to include the union of xCal and 8601 durations.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 23 of 37
402
4.8 Availability
403
4.8.1 Introduction
404
Availability is a means for describing when an actor can be available, or its complement, not available.
405
406
This version of the WS-Calendar PIM includes the necessary classes to express Availability as in
[Vavailability] which is an Internet Draft as of this date.
407
4.8.2 Model Diagram
408
409
Figure 4-8 Vavailability and Availability Recurrence Rules
410
4.8.3 Discussion
411
412
413
The rrule is an xCal recurrence rule as defined in section 8.6.5.3 of [rfc6321]. The recurrence might be
(e.g.) Yearly. In its current form, the expression is in iCalendar syntax, and will need future adaptation to
match the abstraction level of this PIM.
414
4.8.4 Relationship to other PIM Components
415
416
417
Consumes recurrence relationships from Vavailability. Used in consumers of WS-Calendar to express
availability for (e.g.) Demand Response events. [EnergyInteroperation]. Not used by other parts of the
PIM.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 24 of 37
418
5 Examples using the PIM
419
5.1 Introduction
420
421
422
We include several examples drawn from a variety of sources in this chapter. Most were crafted using
[WS-Calendar], [EMIX], and [EnergyInteroperation] and were created to illustrate facility scheduling,
energy scheduling, and related topics.
423
5.2 A Meeting Schedule
424
Consider a meeting scheduled for a specific time – say 2pm and lasting two hours.
425
426
The meeting itself can be represented (and scheduled with attendees) as a single interval with duration
2h.
427
428
To carry out the meeting, there are other activities both before and after, and possibly during, the meeting
time. See Figure 5-1 Simple Meeting Schedule below.
429
430
431
First, the room needs to be set up for the meeting. The Heating, Ventilating, and Air Conditioning system
(HVAC) may need to pre-cool the room for the scheduled number of attendees. And the room needs to
be cleaned up before setup for the next meeting.
432
433
434
435
Each of these activities can be scheduled separately, and done by different actors. But they need to be
completed to set up and restore the room.
Also consider a pre-meeting of the leaders in the room, starting 30 minutes before the main meeting, and
lasting 20 minutes so the leaders can meet and greet attendees.
436
The gluons on the right are references into the sequence of intervals.
437
438
(1) The start of the HVAC pre-cooling is given to the HVAC control system
(2) The start of the main meeting gluon is given to the meeting attendees
439
440
Additional gluons could be given to (e.g.) the room set-up team, pointing to the Prepare Room interval,
and to the Pre-Meeting interval for the meeting leaders.
441
442
443
Additional elaboration might include the pre-purchase of energy for the pre-cooling (or committing in an
energy schedule, which the HVAC control system uses to balance energy use through the day to avoid
demand charges.
444
445
446
Finally, the actions are all based on where you reference the schedule—working back from the start time
(inherited from the start of main meeting gluon) the pre-meeting is 30 minutes earlier, and the setup is 2
hours and 30 minutes earlier.
447
448
449
The HVAC schedule gluon might be all that the control system needs, combined with the knowledge from
the schedule that the meeting is over in 2 hours 30 minutes after the 30 minute pre-cool period, and that
cleanup takes another 30 minutes.
450
451
We have not tried to show all possible schedules and variations – perhaps the setup takes longer but is
finished earlier, using an endbefore tolerance (and a zero endafter tolerance).
452
453
454
455
Note that this schedule may be used for any meeting – the start time can be placed in a gluon that
references the Meeting interval. Likewise, the length could also be inherited from that same gluon. The
structure of the schedule would be determined by facility policy (e.g. “you must allow two hours for
setup”), and the schedule itself is relocatable and reusable.
456
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 25 of 37
457
458
Figure 5-1 Simple Meeting Schedule
459
5.3 An Energy Schedule
460
461
TBD: EnergyInteroperation sequence where the price offered is expressed in three different gluons, but
with the same shared schedule.
462
5.4 Academic Scheduling Example
463
TBD From C.1.1 of [WS-Calendar].
464
5.5 Further Examples from WS-Calendar
465
TBD.
466
NOTE: Consider Examples 3-12, 3-13, and 3-14 from [WS-Calendar].
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 26 of 37
467
5.6 Architectural Approaches
468
TBD.
469
NOTE:
470
471
472
Draw from examples to discuss relocatable sequences, gluons as subroutines (start in 5-1, could be more
clear), and factoring and pushing information up the graph – with fully bound and anchored sequences
derived from more general ones.
473
Selected examples (especially 3-12 and 3-14) from WS-Calendar would be useful.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 27 of 37
474
6 PIM to WS-Calendar PSM Transformation
475
476
477
MDA instances include a Platform-Independent Model (PIM) which is defined in this specification, and a
transformation to a Platform-Dependent Model (PSM). In this section we briefly describe the mapping
from this WS-Calendar PIM to [WS-Calendar].
478
479
By using the same data types and conformed strings for instance values the transformation is
straightforward.
480
481
482
WS-Calendar expresses the information for Intervals, Gluons, and other classes in terms of collections of
Parameters, Properties, and Value Types, held in those collections with others that may not reflect the
abstractions of WS-Calendar.
483
484
485
486
Accordingly, the mapping is from the PIM abstractions and classes to the expression in WS-Calendar
Parameters, Properties, and Value Types. By the construction of names and types, the relationships of
abstract types in the PIM is the same as the relationships of the abstract types in WS-Calendar; the
implementation in terms of Parameters, Properties, and Value Types is exactly that in WS-Calendar.
487
NOTE:
488
489
The text conflates the transformation from a PIM [model] to a PSM [model] with transformation of
instances; this should be made more clear in the next Working Draft
490
6.1 General Transformation
491
6.2 Specific Transformations
492
Use the XML examples from WS-Calendar 1.0 e.g. Line 483
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 28 of 37
493
7 PIM to IEC TC57 CIM Intervals and Sequences
494
TBD
495
496
Consider an example transform between PIM expression and IEC 61968/61970 expression. (WTC note in
progress on this as a separate topic)
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 29 of 37
498
8 Conformance and Rules for WS-Calendar PIM and
Referencing Specifications
499
8.1 Introduction
500
501
502
This Conformance section differs in minor detail from that in [WS-Calendar]. The conformance behavior
is in general identical to that of WS-Calendar; see Appendix D for details. We do not describe changes in
that Appendix that involve the use of the name “WS-Calendar PIM” rather than “WS-Calendar.”
503
This section specifies conformance related to the information model contained in this specification.
504
505
506
If the implementer and/or implementation claiming conformance is using WS-Calendar PIM as part of a
larger business or service communication, they SHALL follow not only the semantic rules herein, but
SHALL also conform to the rules for specifying inheritance in referencing standards.
507
8.2 Relationship to WS-Calendar CS01 [Non-Normative]
508
509
This Platform-Independent Model for WS-Calendar shares all of the conformance statements from WSCalendar CS01 [WS-Calendar] subject to
497
510
511
512
513
514




Renaming of attributes (e.g., UID from [WS-Calendar] is named instanceID)
Disambiguation of rules (e.g., “Intervals SHALL have a Duration AND ( either a dtStart OR a
dtEnd )” in 8.3.5.1)
Simplification (e.g., the section 8.3.5.2)
Rewording to define conformance to WS-Calendar PIM rather than [WS-Calendar].
515
8.3 Conformance Rules for WS-Calendar PIM
516
517
There are five kinds of conformance that must be addressed for WS-Calendar and specifications that
reference WS-Calendar. This PIM references WS-Calendar and requires the same conformance rules.
518

Conformance to the inheritance rules in WS-Calendar, including the direction of inheritance
519

Specific attributes for each type that MUST or MUST NOT be inherited
520

Conformance rules that Referencing Specifications MUST follow
521

Description of Covarying attributes with respect to the Reference Specification
522

Semantic Conformance for the information within the artifacts exchanged
523
We address each of these in the following sections
524
8.3.1 Inheritance in WS-Calendar
525
In this section we define rules that define inheritance including direction.
526
527
I1: Proximity Rule Within a given lineage, inheritance is evaluated though each Parent to the Child
before what the Child bequeaths is evaluated.
528
529
I2: Direction Rule Intervals MAY inherit attributes from the nearest gluon subject to the Proximity Rule
and Override Rule, provided those attributes are defined as Inheritable.
530
531
532
I3: Override Rule If and only if there is no value for a given attribute of a Gluon or Interval, that Gluon or
Interval SHALL inherit the value for that attribute from its nearest Ancestor in conformance to the
Proximity Rule.
533
534
I4: Comparison Rule Two Sequences are equivalent if a comparison of the respective Intervals
succeeds as if each Sequence were fully Bound and redundant Gluons are removed.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 30 of 37
535
536
537
I5: Designated Interval Inheritance [To facilitate composition of Sequences] the Designated Interval in
the ultimate Ancestor of a Gluon is the Designated Interval of the composed Sequence. Special
conformance rules for Designated Intervals apply only to the Interval linked from the Designator Gluon.
538
539
540
541
I6: Start Time Inheritance When a start time is specified through inheritance, that start time is inherited
only by the Designated Interval; the start time of all other Intervals are computed through the durations
and temporal; relationships within the Sequence. The Designated Interval is the Interval whose parent is
at the end of the lineage.
542
8.3.2 Specific Attribute Inheritance
543
544
In WS-Calendar and this PIM the following attributes MUST be inherited in conformance to the Rules
(same for Gluons and Intervals):
545

dtStart
546

dtEnd
547

Duration
548

Designated Interval (Gluon, special upward inheritance rule)
549

Tolerance
550
In WS-Calendar and this PIM the following attributes MUST NOT be inherited
551

instanceUid (Gluons and Intervals)
552

Temporal Relationships (between Intervals)
553

Relationship Links
554
8.3.3 General Conformance Issues
555
556
557
558
This specification is general purpose. Standards that claim conformance to this specification may need to
restrict the variability inherent in the expressions of Date and Time to improve interoperation within their
own interactions. Aspects of Date and Time that may reward attention and conformance statements
include:
559
560

Precision – Does the conforming specification express time in Hours or in milliseconds. Consider
a standard format recommendation.
561
562
563
564
565
566

Time Zones and UTC – Business interactions have a “natural” choice of local, time zone, or UTC
based expression of time. Intents may be local, as they tie to the business processes that drive
them. Tenders may be Time-zone based, as they are driven by the local business process, but
may require future action across changes in time and in time zone. Transaction recording may
demand UTC, for complete unambiguity. The specification cannot require one or another, but
particular business processes may require appropriate conformance statements.
567
568
569
570
571
572
573

Business Purpose – Because WS-Calendar is general purpose, it does not distinguish between
different exchanges that may have different purposes. For example, a general indication of
capability and/or timeliness may be appropriate for a market tender, and an unanchored
Sequence may be appropriate. In the same specification, performance execution could require
merely the Gluon to Anchor the Interval. If the distinction between Unanchored and Anchored
Interval is critical for a set of interactions, the referencing specification SHALL indicate the proper
form for a given exchange.
574
8.3.4 Covarying Elements
575
576
577
578
579
Some elements of WS-Calendar and PIM objects may be covarying, meaning that they change together.
Such elements are treated as a single element for inheritance, they are either inherited together or the
child keeps its current values intact. This becomes important if one or more of a covarying set have
default values. In that case, if any are present, then inheritance should deem they are all present, albeit
some perhaps in their default values.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 31 of 37
580
8.3.5 Conformance of Intervals
581
8.3.5.1 Intervals
582
WS-Calendar PIM Intervals SHALL have a Duration.
583
Intervals MAY have a Start Time.
584
585
Intervals SHALL have a Duration AND optionally dtStart. If a non-compliant Interval is received in a
service operation with dtEnd, then the dtEnd SHALL be ignored.
586
Within a Sequence, a maximum of a single Interval MAY have a dtStart or a dtEnd.
587
8.3.5.2 Other Elements
588
A Gluon may have a dtStart value.
589
8.3.6 Conformance of Bound Intervals and Sequences
590
591
592
Actionable services require Bound Intervals as part of a Bound Sequence. Services may include Intervals
that are not bound for informational or negotiation purposes. Some of these are modeled and described
as constraints in the UML models that have been produced separately.
593
594

Intervals SHALL have values assigned for dtStart and duration, either explicitly or through
inheritance
595

Intervals SHALL have no value assigned for dtEnd
596
597

Within a Sequence at most the Designated Interval may have dtStart and duration with a value
specified or inherited.
598
599

If Sequences are composed to create other Sequences, then the Designated Intervals within the
composing Sequence are ignored.
600
601

Any specification claiming conformance to the WS-Calendar PIM MUST satisfy all of the following
conditions:
602
o
Follow the same style of inheritance (per the Rules)
603
o
Specify attribute inheritability in the specification claiming conformance
604
605
o
Specify whether certain sets of elements must be inherited as a group or specify that all
elements can be inherited or not on an individual basis
607
8.4 Conformance Rules for Specifications Claiming Conformance to
WS-Calendar PIM
608
609
610
611
Specifications that claim conformance to the WS-Calendar PIM SHALL specify inheritance rules for use
within their specification. These rules SHALL NOT modify the Proximity, Direction, or Override Rules. If
the specification includes covariant elements, those elements SHALL be clearly designated in the
specification.
612
613
Specifications that normatively reference and claim conformance with the WS-Calendar PIM SHALL
define the business meaning of zero duration Intervals.
614
8.5 Security Considerations
615
616
617
The WS-Calendar PIM describes an informational model. Specifications claiming conformance with the
WS-Calendar PIM are likely to use the schedule and interval information as but a small part of their
overall communications.
618
619
620
621
Specifications involving communication and messages that claim conformance to this specification should
select the communication and select from well-known methods to secure that communication appropriate
to the information exchanged, while paying heed to the costs of both communication failure and of
inappropriate disclosure. To the extent that iCalendar schedule servers are used, the capabilities of
606
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 32 of 37
622
623
security of those systems should be considered as well. Those concerns are out of scope for this
specification.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 33 of 37
624
Appendix A. Acknowledgments
625
626
The following individuals have participated in the creation of this specification and are gratefully
acknowledged:
627
Participants:
Bruce Bartell
Southern California Edison
Chris Bogen
US Department of Defense (DoD)
Edward Cazalet
Individual
Toby Considine
University of North Carolina at Chapel Hill
Robin Cover
OASIS
William Cox
Individual
Sharon Dinges
Trane
Michael Douglass
Rensselaer Polytechnic Institute
Craig Gemmill
Tridium, Inc.
Dave Hardin
EnerNOC
Gale Horst
Electric Power Research Institute (EPRI)
Gershon Janssen
Individual
Ed Koch
Akuacom Inc.
Benoit Lepeuple
LonMark International
Carl Mattocks
Individual
Robert Old
Siemens AG
Joshua Phillips
ISO/RTO Council (IRC)
Jeremy Roberts
LonMark International
David Thewlis
CalConnect
628
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 34 of 37
629
Appendix B. Revision History
630
Revision
Date
Editor
Changes Made
01
November 15 2012
William Cox
Initial Draft based on contributed models
02
December 20 2012
William Cox
First draft conformance section. Added
explanatory text in individual model sections.
GluonType is now a subclass of IntervalType,
rather than GluonType having an association to
IntervalType.
03
January 31, 2012
William Cox
Completed most sections; indicated questions
for the TC as “EDITOR’S NOTE”s. Model is
the same as for WD02. WD03 contains a
quotation with modifications from the WSCalendar conformance sections.
04
April 10, 2013
William Cox
Update with responses to questions from
WD03; minor changes to the model and many
clarifications based on meeting discussions.
Included differences between the normative
semantics and conformance sections and WSCalendar 1.0 as non-normative Appendices.
05
April 24, 2013
William Cox
Addressed remaining Editor’s Notes from
previous Working Drafts. Changed cardinality
for attachment from [1..1] to [0..1] in parallel
with unbound attributes expressed in UML.
Prepared text for public review.
06
16 January 2014
William Cox
Simplification of relations and LinkType.
Addition of instance (object) diagrams to
express examples. Includes PIM to WSCalendar-as-PSM mapping.
07
17 January 2014
William Cox
Addresses comments from TC review of
WD06. Eliminated unused
DurationParameterEnum, corrected gap to
DurationStringType (with no tolerance values),
eliminated iana-token and x-name relationship
types. Identified but did not correct the
application of tolerance to dtStart, dtEnd, and
duration. Clarified intended sources of
examples. Eliminated unused classes and
objects in the model.
631
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 35 of 37
633
Appendix C. PIM and WS-Calendar Semantics
Differences
634
635
The following is a non-normative list of changes required to convert the [WS-Calendar] Section 1.9
Semantics section to the Semantics section of the PIM.
636
637
We have excluded changes to table numbering, page footers, and purely typographic changes such as
deletion of extra spaces.
638
Line numbers are with respect to [WS-Calendar] in PDF form.
632
Line Number
Change to [WS-Calendar] to PIM
200-201
Added references to WS-Calendar and PIM tables
202 Table 1-3, Gluon Entry
Changed “…gluon is influences…” to “…gluon
influences…” (typographic)
202 Table 1-3, Artifact Entry
Changed first sentence to “An Artifact is the
information attached to, and presumably that
occurs or is relevant to the time span described by
an Interval.”
208, Table 1-4, Busy Entry
Changed “Busy often overlays is overlaid by
Availability” to “Busy often overlays Availability.”
639
640
NOTE: This table was current as of PIM WD05; needs to be updated.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 36 of 37
642
Appendix D. PIM and WS-Calendar Conformance
Differences
643
644
The following is a non-normative list of changes required to convert the [WS-Calendar] Section 4
Conformance and Rules for WS-Calendar and Referencing Specification to Section 5 of the PIM.
645
646
647
We have excluded changes to table numbering, page footers, and purely typographic changes such as
deletion of extra spaces. Text was reworded to refer to the PIM rather than WS-Calendar as needed;
such changes are not captured here.
648
Line numbers are with respect to [WS-Calendar] in PDF form.
641
Line Number
Change to [WS-Calendar] to PIM
1450-1453 Introduction
Modified Introduction to apply to the WS-Calendar
PIM.
1490
Changed “UID (Gluons and Intervals)” to
“instanceUid (Gluons and Intervals)”
1491
Added “Relationship Links” to list.
1522-1523
Changed “Duration AND a dtStart OR a dtEnd” to
“Duration AND optionally dtStart.” Changed
“received with both a dtStart and a dtEnd then the
dtEnd SHALL be ignored” to” “received in a service
operation with dtEnd then the dtEnd SHALL be
ignored.”
1525-1529
Replaced with “A Gluon may have a dtStart value>”
Other conditions are excluded by the UML in PIM.
1550
Change “override” to “modify” […the Proximity,
Direction, or Override Rules.]
649
650
NOTE: This table was current as of PIM WD05; needs to be updated.
ws-calendar-pim-v1.0-wd07
Standards Track Draft
Working Draft 07
Copyright © OASIS Open 2012.-2014 All Rights Reserved.
17 January 2014
Page 37 of 37