WS-Calendar Platform Independent Model (PIM) Version 1.0
Committee Specification Draft 03
15 August2014
Specification URIs
This version:
(Authoritative)
Previous version:
(Authoritative)
Latest version:
(Authoritative)
Technical Committee:
OASIS Web Services Calendar (WS-Calendar) TC
Chair:
Toby Considine (), University of North Carolina at Chapel Hill
Editors:
William Cox (), Individual
Toby Considine (), University of North Carolina at Chapel Hill
Additional artifacts:
This prose specification is one component of a Work Product, which also includes:
- XMI (UML in XML) documents representing the UML model described in the specification. XML is authoritative; EAP file is informative:
Related work:
This specification is related to:
- WS-Calendar Version 1.0. Edited by Toby Considine and Mike Douglass. Latest version.
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 document was last revised or approved by the OASIS Web Services Calendar (WS-Calendar) TCon the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document.Any other numbered Versions and other technical work produced by the Technical Committee (TC) arelisted at
TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’spublic comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (
Citation format:
When referencing this specification the following citation format should be used:
[WS-Calendar-PIM-v1.0]
WS-Calendar Platform Independent Model (PIM) Version 1.0. Edited by William Cox and Toby Considine. 15 August 2014. OASIS Committee Specification Draft 03. Latest version:
Notices
Copyright © OASIS Open2014. 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.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The name "OASIS"is a trademarkof OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see for above guidance.
Table of Contents
Table of Figures
List of Tables
1Introduction
1.1 Terminology
1.2 Normative References
1.3 Non-Normative References
1.4 Namespace
1.5 Naming Conventions
1.6 Editing Conventions
2Architectural Context [Non-Normative]
2.1 Architectural Basis for the PIM
2.2 Standards for Representation of Time
2.3 Service-Oriented Architecture and the PIM
2.4 Model Driven Architecture
2.5 The PIM and the WS-Calendar PSM
2.6 Expression of the PIM UML Model
2.7 Structure of the PIM Model and Specification
3WS-Calendar PIM Terminology and Semantics
3.1 Time Intervals and Collections of Time-Related Intervals
4The Platform-Independent Model
4.1 Overview of the PIM
4.1.1 Model Diagram
4.1.2 Discussion
4.2 Classes for Date and Time, Duration, and Tolerance
4.2.1 Model Diagram
4.2.2 Discussion
4.2.3 Relationship to other PIM Components
4.3 The Interval Class
4.3.1 Model Diagram
4.3.2 Discussion
4.3.3 Relationship to other PIM Components
4.4 Payload Attachment to an Interval
4.4.1 Model Diagram
4.4.2 Discussion
4.4.3 Relationship to other PIM Components
4.5 The Gluon Class
4.5.1 Model Diagram
4.5.2 Discussion
4.5.3 Relationship to other PIM Components
4.6 Relationships among Gluons and Intervals
4.6.1 Model Diagram
4.6.2 Discussion
4.6.3 Relationship to other PIM Components
4.7 The Availability Package
4.7.1 Model Diagram
4.7.2 Discussion
4.7.3 Relationship to other PIM Components
5Rules for WS-Calendar PIM and Referencing Specifications
5.1 Inheritance in WS-Calendar PIM
5.2 Covarying Elements
5.3 Specific Attribute Inheritance
6Conformance
6.1 Conformance for Specifications Claiming Conformance to WS-Calendar PIM
6.2 General Conformance Issues (Non-Normative)
6.3 Conformance of Intervals
6.3.1 Intervals and Gluons
6.3.2 Other Attributes
6.4 Conformance of Bound Intervals and Sequences
6.5 Security Considerations (Non-Normative)
7Examples using the PIM (Non-Normative)
7.1 Related Intervals
7.2 A Meeting Schedule
Appendix A.Acknowledgments
Appendix B.Revision History
Appendix C.PIM to WS-Calendar PSM Transformation
C.1 General Transformations
C.2 Specific Transformations
C.2.1 Transformation for DateTime and Duration Types
C.2.2 Transformation for Tolerance Type
C.2.3 Transformation for Interval and Gluon Types
C.2.4 Transformation for Relationships
C.2.5 Transformation for Vavailability and FreeBusy
Appendix D.PIM to IEC TC57 CIM Intervals and Sequences (Non-Normative Example)
Table of Figures
Figure 41 The Complete WS-Calendar PIM UML Model. Abstract classes have violet background.
Figure 42 DateTimeType, DurationType, and ToleranceType
Figure 43 IntervalType
Figure 44 Attaching a Payload to an Interval
Figure 45 Gluons, Intervals, and Relationship Links
Figure 46 Temporal Relationships
Figure 47 Temporal Relationship--startToFinish Negative 0.5 Gap
Figure 48 RelationLinkType and Relationship Types
Figure 49 Vavailability and Availability Recurrence Rules
Figure 71 PIM Expression of WS-Calendar Examples 3-05
Figure 72 Simple Meeting Schedule
Figure 73 PIM Source Classes for DateTimeType and Duration Types
Figure 74 WS-Calendar Target Classes
Figure 75 PIM Source Class for ToleranceType
Figure 76 WS-Calendar Target Classes for Tolerance Type
Figure 77 PIM IntervalType and GluonType
Figure 78 WS-Calendar Target IntervalType and GluonType
Figure 79 PIM RelationLinkType, LinkType, RelationshipType, and TemporalRelationshipType
Figure 710 PIM Vavailability Package Classes
Figure 711 Vavailability Package from iCalendar-availability-extension
List of Tables
Table 31: Semantics: Foundational Elements
Table 32: Semantics: Relations, Limits, and Constraints
Table 33: Semantics: Inheritance
Table 34: Semantics: Describing Intervals
Table 71 PIM to PSM Mapping for DateTimeType and Duration Types
Table 72 PIM to PSM Mapping for ToleranceType
Table 73 PIM to PSM Mapping for IntervalType and GluonType
Table 74 PIM to PSM Mapping for Attributes of PIM RelationshipType and TemporalRelationshipType
Table 75 PIM to PSM Mapping for Enumeration Members
ws-calendar-pim-v1.0-csd0315 August 2014
Standards Track Work ProductCopyright © OASIS Open 2014. All Rights Reserved.Page 1 of 46
1Introduction
All text is normative unless otherwise labeled. Notes and examples are non-normative; see Section 1.6Editing Conventions.
1.1Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
1.2Normative References
[ISO8601]ISO (International Organization for Standardization). Data elements and interchange formats -- Information interchange -- Representation of dates and times,Edition 3, 3 December 2004, (ISO 8601:2004)
[RFC3986]Berners-Lee, T., Fielding, R., and L. Masinter, Uniform Resource Identifier (URI): Generic Syntax, STD 66, RFC 3986, January 2005.
[RFC2119]Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997.
[RFC5545]Desruisseaux, B.Internet Calendaring and Scheduling Core Object Specification (iCalendar), RFC5545, September 2009
[UML]OMGUnified Modeling Language (OMG UML), Infrastructure, Version 2.4.1, Object Management Group. OMGUnified Modeling Language (OMG UML), Superstructure, Version 2.4.1, Object Management Group, August 2011
[xCal]Daboo, C., Douglass, M., and S. Lees, xCal: The XML format for iCalendar, IETF RFC 6321, August 2011.
[XMI]MOF 2.0/XMI Mapping Specification, v2.1, September 2005, Object Management Group,
1.3Non-Normative References
[BPEL]Web Services Business Process Execution Language Version 2.0, 11 April 2007,OASIS Standard.
[BPMN]Business Process Model and Notation (BPMN) Version 2.0, Object Management Group, Version 2.0, January 2011
[EnergyInterop-v1.0]Energy Interoperation Version 1.0. Edited by Toby Considine.11 June 2014. OASIS Standard. Latest version: PDF is authoritative.
[EnterpriseArchitect]SparxEnterprise Architect 10.0, used to produce [UML] 2.4.1 diagrams, EAP and [XMI] version 2.1 files,
[IANA]The Internet Assigned Numbers Authority,
[IEC CIM]IEC 61968/61970, International Electrotechnical Commission, collection of specifications, various dates,
[MDA-Overview]The Architecture of Choice for a Changing World, Object Management Group,
[MDA]OMG Model Driven Architecture Specifications, Object Management Group,
[PIM Examples]Examples for WS-Calendar Platform-Independent Model (PIM) Version 1.0, OASIS Committee Technical Note,in progress.
[Relationships]M. Douglass, Support for Icalendar Relationships, IETF Internet Draft Version 02, January 7, 2014
[SOA-RAF]Reference Architecture Foundation for Service Oriented Architecture Version 1.0, 04 December 2013.OASIS Committee Specification. is authoritative.
[SOA-RM]OASIS Reference Model for Service Oriented Architecture 1.0,October 2006. OASIS Standard.
[Vavailability]C. Daboo, M. Douglass, Calendar Availability, IETF Internet Draft Version 05, January 30, 2014
WS-Calendar]WS-Calendar Version 1.0. Edited by Toby Considine and Mike Douglass. 30 July 2011, OASIS Committee Specification. (PDF is authoritative)
[XMLSchema]W3C XML Schema Definition Language (XSD) 1.1, World Wide Web Consortium, Part 1: Structures, S. Gao, C. M. Sperberg-McQueen, H. S. Thompson, N. Mendelsohn, D. Beech, M. Maloney, Editors, W3C Recommendation, 5 April 2012, Latest version available at Part 2: Datatypes, D. Peterson, S. Gao, A. Malhotra, C. M. Sperberg-McQueen, H. S. Thompson, P. Biron, Editors. W3C Recommendation, 5 April 2012, Latest version available at
1.4Namespace
There are no XML namespaces defined in this specification.
1.5Naming Conventions
This specification follows a set of naming conventions for artifacts defined by the specification, as follows:
For the names of attributes in UML classes the names follow the lower camelCase convention, with all names starting with a lower case letter. For example, an attribute name might be
temporalRelationship
The names of UML classes follow the upper CamelCase convention with all names starting with an Upper case letter followed by “Type“.
TemporalRelationshipType
The UML Primitive Type String[UML, Infrastructure][3]is used in this specification.
1.6Editing Conventions
For readability, UML attribute names in tables appear as separate words. The actual names are lowerCamelCase, as specified above, and do not contain spaces.
Attribute and type names are usually in an italic face.
All items in the tables not marked as “optional” are mandatory.
Information in the “Specification” column of tables is normative. Information appearing in the “Note” column is non-normative.
Text indicated as “Note” are non-normative.
All sections explicitly described as examples are non-normative.
All examples with gray highlight are non-normative.
All Appendices are non-normative.
2Architectural Context [Non-Normative]
In this section we discuss the context in which this specification was developed, its purpose, and selected applications.
2.1Architectural Basis for the PIM
The PIM is defined as a more abstract model for describing and communicating schedules as defined in [WS-Calendar], [EMIX], [EnergyInterop-v1.0], [OBIX], and [SPC201], among many others. This expression uses typical ways of expressing schedule, linked lists, directed graphs, and is consistent with algorithms for graph, list, and schedule management.
In summary, there are several anticipated architectural benefits of the PIM:
- Expression of schedules in a common manner showing temporal structures and taking advantage of differing views of a single schedule
- Relocatable subroutines that may be used dynamically at run time
- Automatable transformations between the abstract and concrete schedules in the PIM and WS-Calendar respectively
- Broader use of scheduling concepts in other domains and PSMs allowing automatable transformations across other domains
Schedule and values attached to time intervals in schedule are fundamental to planning and carrying out operations is most domains. The WS-Calendar PIM provides a common model for expressing and managing such schedules.
2.2Standards for Representation of Time
We rely on [ISO8601] for description of date, time, and duration. Many of the concepts in that standard are well known to users of iCalendar [RFC5545] and XML Schema [XMLSchema], both of which share similar but slightly different subsets of the expressive power of [ISO8601]. For example, we define a conformed string for an attribute called ISO8601Duration which differs in detail from the perhaps more familiar XML Schema and iCalendar.
PSMs may restrict or profile time expressions in the PIM. For example, many industrial control systems define time intervals with start and end time, which is a conformant 8601 definition. For purposes of relocatable schedules, as used in e.g. [EMIX] and [EnergyInterop-v1.0] this PIM uses start time and duration only, another conformant 8601 definition.
2.3Service-Oriented Architecture and the PIM
WS-Calendar PIM is an information model that may be used to define service request and response message payloads. For that purpose it assumes a background of definitions and of roles, names, and interaction patterns. Non-normative examples may use terminology defined in the OASIS Standard Reference Model for Service Oriented Architecture[SOA-RM].
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 Platform-Specific Models based on this PIM.
2.4Model Driven Architecture
The Object Management Group’s Model Driven Architecture [MDA-Overview][MDA] provides a framework to describe relationships between Unified Modeling Language [UML] models.
An instance of MDA has two classes of models:
- A single Platform-Independent Model, abbreviated PIM (pronounced as though spelled pim)
- One or more Platform-Specific Models, abbreviated PSM (pronounced as though spelled pism)
The PIM typically captures the more abstract relationships, clarifying the architecture. Each PSM is bound to a particular platform.
The art of establishing an MDA includes defining platforms and a PIM and PSMs, to solve interesting 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.
2.5The PIM and the WS-Calendar PSM
In this specification we define a PIM or Platform-Independent Model with respect to which the [WS-Calendar] specification may be treated as a PSM or Platform-Specific Model; the platform may be considered to be iCalendar [RFC5545], [xCal], and [Vavailability].
We use “the PIM” to mean “the WS-Calendar PIM” in this specification.
[iCalendar] uses a set of definitions and a platform, developed over many years and much use, to express relationships, times, events, and availability. The expression is very simple, but in the aggregate relatively complex and less suitable to UML expression—the several key types (components) have sets of values, types, and parameters associated with them in a relatively flat hierarchy.