[GRAAP-WG] [Fwd: Fwd: [members] Proposed Charter for OASIS Web Services Calendar (WS-Calendar) TC]

Wed Jan 6 07:40:14 CST 2010

Dear All,

related to our discussions on an Advance Reservation profile this might
be of interest.

Best regards, Philipp.

------- Forwarded message -------
From: "Mary McRae" <mary.mcrae at oasis-open.org>
To: members at lists.oasis-open.org, tc-announce at lists.oasis-open.org
Cc: oasis-charter-discuss at lists.oasis-open.org
Subject: [members] Proposed Charter for OASIS Web Services Calendar
(WS-Calendar) TC
Date: Wed, 06 Jan 2010 13:12:26 +0900

To OASIS Members:

   A draft TC charter has been submitted to establish the Web Services
Calendar (WS-Calendar) Technical Committee (below). In accordance with the
OASIS TC Process Policy section 2.2:
(http://www.oasis-open.org/committees/process-2009-07-30.php#formation)
the proposed charter is hereby submitted for comment. The comment period
shall remain open until 11:45 pm ET on 19 January 2010.

   OASIS maintains a mailing list for the purpose of submitting comments on
proposed charters. Any OASIS member may post to this list by sending email
to:
mailto:oasis-charter-discuss at lists.oasis-open.org. All messages will be
publicly archived at:
http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who
wish to receive emails must join the group by selecting "join group" on
the group home page:
http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/.
Employees of organizational members do not require primary representative
approval to subscribe to the oasis-charter-discuss e-mail.

   A telephone conference will be held among the Convener, the OASIS TC
Administrator, and those proposers who wish to attend within four days of
the close of the comment period. The announcement and call-in information
will be noted on the OASIS Charter Discuss Group Calendar.

   We encourage member comment and ask that you note the name of the
proposed TC (WS-Calendar) in the subject line of your email message.

Regards,

Mary

Mary P McRae
Director, Standards Development
Technical Committee Administrator
OASIS: Advancing open standards for the information society
email: mary.mcrae at oasis-open.org
web: www.oasis-open.org
twitter: @fiberartisan #oasisopen
phone: 1.603.232.9090

-----

Web Services Calendar (WS-Calendar) Technical Committee

1. Normative Information

a. Name
Web Services Calendar (WS-Calendar) Technical Committee

b. Statement of Purpose
One of the most fundamental components of negotiating services is agreeing
when something should occur, and in auditing when they did occur. Short
running services have traditionally been handled as if they were
instantaneous, and thereby dodged this requirement through just-in-time
requests. Longer running processes may require significant lead times.
When multiple long-running services participate in the same business
process, it may be more important to negotiate a common completion time
than a common start time. Central coordination of such services reduces
interoperability as it requires the coordinating agent to know the lead
time of each service.

Other processes may have multiple and periodic occurrence. Identical
processes may need to be requested on multiple schedules. Other processes
must be requested to coincide with or avoid human interactions. An example
is a process that occurs on the first Tuesday of every month. Others may
need to be completed on schedules that vary by local time zone.

Physical processes are now being coordinated by web services. Building
systems and industrial processes are operated using oBIX, BACnet/WS,
LON-WS, OPC XML, and a number of proprietary specifications including
TAC-WS, Gridlogix EnNet, and MODBUS.NET. Energy use in buildings can be
reduced while improving performance if building systems are coordinated
with the schedules of the buildings occupants.

An increasing number of specifications envision synchronization of
processes through mechanisms including broadcast scheduling. Efforts to
build an intelligent power grid (or smart grid) rely on coordinating
processes in homes, offices, and industry with projected and actual power
availability, including different prices at different times. Two active
OASIS Technical Committees require a common means to specify schedule and
interval: Energy Interoperation (EITC) and Energy Market Information
Exchange (EMIX). Emergency management coordinators wish to inform
geographic regions of future events, such as a projected tornado
touchdown, using EDXL. These efforts would benefit from a common standard
for transmitting schedule and interval.

For human interactions and human scheduling, the well-known iCalendar
format is used. Today, there is no equivalent standard for web services.
As an increasing number of physical processes are managed by web services,
the lack of a similar standard for scheduling and coordination of services
becomes critical.

The goal of WS-Calendar is to adapt the existing specifications for
calendaring and apply them to develop a standard for how schedule and
event information is passed between and within services. The standard
should adopt the semantics and vocabulary of iCalendar for application to
the completion of web service contracts.

A calendar event without an associated contract is of little use.
WS-Calendar will be a micro-specification, and then a micro-standard.
WS-Calendar is unlikely to be used by itself. WS-Calendar will instead be
used inside other specifications and standards, bringing a common
scheduling function to diverse interactions in different domains.

c. Scope of Work of the WS-Calendar Technical Committee
The Committee will start work with the canonical XML serialization of the
updated iCalendar (IETF RFC 5545), hereafter referred to as iCalendar XML,
as developed by the Calendaring and Scheduling Consortium
(CalConnect.org). This work will provide the vocabulary for use in this
web service component.

The committee will also use as a starting point the forthcoming
calendaring web service specifications being developed by the CalConnect.
This specification provides the basic mechanism for creating, updating,
and deleting calendar events that are common to all calendars and
schedules.

The committee expects that use cases and requirements will be contributed
by other groups, including the NAESB task forces on smart grid prices and
schedules for DR/DER as well as the work done within the oBIX TC to
schedule building systems. These use cases will test the completeness and
functionality of the specification.

The committee will develop additional Calendar functionality in later
work, both in revisions and new specifications. The committee will also
accept additional use cases for profile development, centralizing profile
development to ensure consistency and interoperation of the additional
schedule- and interval-related components.

d. A list of deliverables, with projected completion dates.
The committee will deliver a standard schema and semantics for schedule
and interval information for use in other web services. This specification
will be derived from and compatible the existing iCalendar XML
specification and offer some or all of the functionality of that
specification.

The completed specification should include a standard for referring to
instances of iCalendar XML within a larger payload, as well as a means to
refer to objects external to the iCalendar XML instances. A single
calendar object may be referenced by multiple contracts. A series of
calendar events may reference a single contract.

The committee will deliver a specification for creating, retrieving,
updating, and deleting calendar events on a schedule. This specification
will be based on the forthcoming calendar web service specifications
developed by the CalConnect.

Geoposition is an optional component of the iCalendar XML structure.
Several of the use cases would benefit from geo-location. Some benefit
more from a point, and some from a region or polygon. The committee work
will include recommendations on how to reference geospatial information,
both point and polygon, from within schedule and interval components.
Preference will be given to specifications promulgated by the Open
Geospatial Consortium (OGC, http://www.opengeospatial.org/ ).

The committee will encourage members and others to develop reference
implementations of the schedule components necessary to support the NAESB
and oBIX use cases as described above. These implementations will test the
completeness and functionality of the specification. These profiles will
be donated to the EMIX, EITC, and oBIX Technical Committees at completion
of the initial version of WS-Calendar. The committee may choose to
incorporate additional use cases from other sources into its initial work.

Version 1 of the specification and reference implementation for building
systems and smart grid interactions are anticipated to be complete six
months after the initial meeting.

This is an aggressive schedule, in support of the NIST smart grid priority
actions,
(http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP04Schedules),
and dependent on aggressive results from the other priorities as well.

The committee will add additional functionality to later versions of the
specification as agreed upon by the committee. The committee will also
address additional use cases from additional domains for reference
implementation, with a goal of to ensuring consistency and interoperation
of any additional Calendar and Schedule-related components.

e. IPR Mode for the Committee
The Committee will operate under the OASIS Non-Assert mode.

f. Anticipated audience or users of the WS-Calendar specification
i. oBIX plans to use the scheduling specification for exchange of
information with enterprise and external services. There is a natural and
easy use case for oBIX that looks like "Conference room scheduled for 17
people at 3:00, tell building systems to establish
temperature/humidity/warm up equipment by 3:00 Ventilation adequate for 17
people and continue to do so for the full hour"
(www.oasis-open.org/committees/obix/).

ii. Collaborative energy presents a number of use cases for coordinating
Demand Response (DR), Distributed Energy Resources (DER), and other
transactions associated with the power grid. These economic transactions
need scheduling both for time of day pricing and for scheduled power
generation and use. This work is being done in the Energy Interoperation
TC (EITC) (www.oasis-open.org/committees/energyinterop/). Current EITC
work plans anticipate incorporating this work.

iii. Schedule & interval are critical parts of energy product definition,
for both current and forward energy markets. This work is being done in
the Energy Market Information Exchange (EMIX) TC
(www.oasis-open.org/committees/emix/). Current EMIX work plans anticipate
incorporating this work.

iv. Emergency management would like to be able to transmit warnings and
predictions of upcoming events. A common scheduling component would aid in
cross-domain communications. A schedule component has been anticipated for
future EDXL communications (http://www.oasis-emergency.org/committees).

v. BPEL does not currently have any good way to handle the repeating event
or several time coordinated events. A specification for scheduling could
be incorporated in future versions of BPEL and its offshoot BPEL4People
(www.oasis-open.org/committees/bpel4people/).

vi. The OSCRE developed specification for the exchange of service work
orders would benefit from the addition of a common scheduling and
coordination function, including one which supports repetitive scheduling.
Such a specification could also be used to specify windows during which
the performance of work would minimally inconvenience building occupants.
Alignment of building performance and tenant activity may become part of
new business interactions such as Green Leases. Further work in this area
would be developed by PISCES (http://web.pisces.co.uk/).

vii. Electronic medical records and shared medical services are receiving
growing attention. Many medical services are provided by many service
providers working, occasionally, in concert. A common calendaring function
would aid in coordinating these services across organizational boundaries
to the patients benefit.

viii. HAVE (Hospital Availability Exchange) could be improved if equipment
availability and maintenance schedules could easily be shared in advance.
HAVE is part of the OASIS Emergency Interoperability suite section
(http://www.oasis-emergency.org/committees).

ix. The Green Grid (www.TheGreenGrid.org) is concerned with the
interactions between data centers and the critical resources that support
them. These resources symmetrically share availability and planned
maintenance information with the data center.

x. The OASIS Technical Committee for WS-Device Discovery and Device
Profiles (WS-DD) includes members with an interest in devices of concern
to the oBIX, Demand-Response, and Green Grid. A schedule and interval
specification could add an availability component to the Device Profile.

g. Language of the Technical Committee
The language of the committee shall be English.

2. Non-Normative Information on WS-Calendar

a. Similar Work being done in OASIS or Other Organizations
The definitive work on schedule and interval is the IETF standards
iCalendar RFC2445, iTIP RFC2446, and iMIP RFC2447. Those standards are
being updated for extensibility by the Calendar and Scheduling Consortium
(www.calconnect.org) as RFC 5546, a draft updated ITIP, and an updated
iMIP. CalConnect plans to contribute a canonical XML serialization of
iCalendar to the technical committee.

Standards for Calendaring, or for specifying schedule, and interval
include but are not limited to:
i. iCalendar, also known as RFC 5545
(http://www.ietf.org/rfc/rfc5545.txt). iCalendar describes the base
semantics and vocabulary to be delivered. The committee may choose to
limit the functionality included to a subset of that offered by iCalendar.

ii. hCalendar is a simple, open, distributed calendaring and events
format, based on RFC 2445, (http://microformats.org/wiki/hcalendar)
suitable for embedding in HTML or XHTML. There are concerns and
incompatibilities surrounding the use of hCalendar. See
http://www.sitepoint.com/blogs/2008/06/25/bbc-rejects-hcalendar-microformat-because-of-accessibility-concerns/

iii. HTML 5.0 defines microdata, including a calendar component
(http://www.w3.org/TR/html5/microdata.html#vevent). The vevent is a fork
off an earlier version of iCalendar. Currently, we anticipate that HTML
5.0 will instead reference the iCalendar XML specification.

iv. Open Building Information Exchange (oBIX) has worked since May 2008 to
solve this problem within an OASIS TC. This work is incomplete.
(http://lists.oasis-open.org/archives/obix/)

v. The Open Knowledge Initiative (OKI) has developed an Open Service
Interface Definition (OSID) for Scheduling. The Scheduling OSID provides a
means of associating Agents with specific activities (ScheduleItems). This
OSID provides a way for an application to integrate or use an external
calendaring system, such as an existing Enterprise calendar system.
http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/o/ok/okiproject/OSID_Scheduling_rel_2_0.pdf

vi. CalDAV is a protocol to access server-based schedules and calendars by
means of extensions to the WEBDAV protocol. CalDAV is also referred to as
RFC 4791 (http://www.ietf.org/rfc/rfc4791.txt).

vii. Microsoft offers the WS-Exchange functions for calendaring.
http://msdn.microsoft.com/en-us/library/aa564001(EXCHG.80).aspx
http://msdn.microsoft.com/en-us/library/aa564690(EXCHG.80).aspx

viii. Google calendar defines an XML API for calendar activity with
growing use in devices such as Android phones. Interoperating with this
API is incorporated into the mission of CalConnect.
(http://code.google.com/apis/calendar/data/2.0/developers_guide_protocol.html#CreatingSingle).
As well as these schedule and interval, the iCalendar format includes a
Geo-position element, which has been limited to a point. Several of the
use cases for WS-Calendar would benefit from geo-location. Some would
benefit more from a point, and some from region or polygon. This suggests
that an additional source of IP for WS-Calendar would be at:

ix. The Open Geospatial Consortium (OGC) offers standards for the
interchange of geospatial data. The OGC is the preferred source for
micro-specifications of geospatial data by WS-Calendar.
(http://www.opengeospatial.org/) The committee would reach out to the
Consortium for advice as to which geospatial standards to use.

b. Date and Time of the First Meeting
The first meeting will be February 26 at 2pm US Eastern Time. The meeting
will be by teleconference sponsored by CalConnect.

c. On-Going Meeting Schedule
We anticipate the committee will meet weekly by teleconference sponsored
by CalConnect or other TC members.

d. Contact Information for TC Supporters
David Thewlis, Dave.Thewlis at calconnect.org, CalConnect
David Wollman, david.wollman at nist.gov , NIST
David Holmberg, david.holmberg at nist.gov , NIST
Ron Bernstein, ron at lonmark.org , LonMark International
Jeremy Roberts, jeremy at lonmark.org , LonMark International
David Burke, dburke at tibco.com, TIBCO Software Inc
Larry Lackey, llackey at tibco.com , TIBCO Software Inc
Derek LaSalle, derek.n.lasalle at jpmorgan.com , JP MorganChase
Marquart Franz, marquart.franz at siemens.com , Siemens
Bob Old, bob.old at siemens.com , Siemens
Michel Kohanim, michel at universal-devices.com
William Cox, wtcox at coxsoftwarearchitects.com
Toby Considine, Toby.Considine at unc.edu , University of North Carolina

e. Name, Email Address, and Statement of Support from Primary
Representatives of Organizational Members
* David Thewlis, (Dave.Thewlis at calconnect.org), CalConnect:  The
Calendaring and Scheduling Consortium supports the formation of the OASIS
WS-Calendar Technical Committee.
* NIST: David Flater (dflater at nist.gov ): NIST supports the formation of
the OASIS WS-Calendar Technical Committee.
* LonMark International: Ron Bernstein (ron at lonmark.org ): We are in full
support.
* TIBCO Software Inc: David Burke (dburke at tibco.com ): TIBCO will support
the WS-Calendar initiative.
* JPMorganChase: Derek LaSalle (derek.n.lasalle at jpmorgan.com ): As head of
Information Architecture at the JPMorgan Investment Bank, I support the
formation of the OASIS WS-Calendar Technical Committee.
* Siemens AG: Marquardt Franz (marquart.franz at siemens.com ): As Siemens AG
primary OASIS representative, Siemens can be a supporter of OASIS
WS-Calendar TC.
* University of North Carolina: Toby Considine (Toby.Considine at unc.edu):
The University of North Carolina supports the formation of the WS-Calendar
Technical Committee as described in the WS-Calendar draft charter.

f. Committee Convener
David Thewlis, Calendaring and Scheduling Consortium

g. Member Section
WS-Calendar expects to affiliate with the OASIS Blue Member Section

h. List of Contributors of Existing Technical Work
The TC will base its work on the IETF iCalendar RFCs. Other contributions
are pending.

i. Draft Frequently Asked Questions
None.

j. Proposed Working Title and Acronym for the Specification(s) to be
Developed by the TC
OASIS Common Scheduling.

---------------------------------------------------------------------

This email list is used solely by OASIS for official consortium
communications.

Opt-out requests may be sent to member-services at oasis-open.org, however,
all members are strongly encouraged to maintain a subscription to this
list.

-- 
Andreas Savva
Fujitsu Laboratories Ltd