I understand that, guess I don't like the work "expects", which is not the same as will request affiliation to.
>
Original Message-----
> From: Mary McRae [mailto:mary.mcrae@oasis-open.org]
> Sent: 11 January 2010 16:51
> To: Martin Chapman
> Cc: oasis-charter-discuss@lists.oasis-open.org
> Subject: Re: [oasis-charter-discuss] Proposed Charter for OASIS Web Services Calendar (WS-Calendar) TC
>
> In response to item 2g, affiliation with a Member Section is a multi-step process. A proposed charter
> can only specify that the group intends to affiliate or expects to affiliate with a Member Section.
> Once the charter is finalized (when the Call for Participation is issued), the Member Section must
> then vote to accept the TC into the Member Section.
>
> Regards,
>
> Mary
>
>
>
> On Jan 11, 2010, at 11:38 AM, Martin Chapman wrote:
>
> > Comments:
> >
> > 1. b last para - what is a "micro"-specification and a
> > "micro"-standard, and in the context of oasis why mention this at all since spec to standard is part
> of the TC process.
> >
> > 2g. OASIS Blue Member section, what is being part of this contingent on? The proposers either want
> it part of the MS or not.
> > 2j. why is the proposed name of the specification not ws-calendar.
> >
> >
> >>
Original Message-----
> >> From: Mary McRae [mailto:mary.mcrae@oasis-open.org]
> >> Sent: 06 January 2010 04:12
> >> To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org
> >> Cc: oasis-charter-discuss@lists.oasis-open.org
> >> Subject: [oasis-charter-discuss] Proposed Charter for OASIS Web
> >> Services Calendar (WS-Calendar) TC
> >>
> >> 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#formatio
> >> n) 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@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@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-micro
> >> format-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/sourc
> >> eforge/o/ok/okiproject/OSID_Sched
> >> uling_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@calconnect.org, CalConnect David Wollman,
> >> david.wollman@nist.gov , NIST David Holmberg, david.holmberg@nist.gov
> >> , NIST Ron Bernstein, ron@lonmark.org , LonMark International Jeremy
> >> Roberts, jeremy@lonmark.org , LonMark International David Burke,
> >> dburke@tibco.com, TIBCO Software Inc Larry Lackey, llackey@tibco.com
> >> , TIBCO Software Inc Derek LaSalle, derek.n.lasalle@jpmorgan.com , JP
> >> MorganChase Marquart Franz, marquart.franz@siemens.com , Siemens Bob
> >> Old, bob.old@siemens.com , Siemens Michel Kohanim,
> >> michel@universal-devices.com William Cox,
> >> wtcox@coxsoftwarearchitects.com Toby Considine,
> >> Toby.Considine@unc.edu , University of North Carolina
> >>
> >> e. Name, Email Address, and Statement of Support from Primary
> >> Representatives of Organizational Members
> >> * David Thewlis, (Dave.Thewlis@calconnect.org), CalConnect: The
> >> Calendaring and Scheduling Consortium supports the formation of the OASIS WS-Calendar Technical
> Committee.
> >> * NIST: David Flater (dflater@nist.gov ): NIST supports the formation
> >> of the OASIS WS-Calendar Technical Committee.
> >> * LonMark International: Ron Bernstein (ron@lonmark.org ): We are in full support.
> >> * TIBCO Software Inc: David Burke (dburke@tibco.com ): TIBCO will support the WS-Calendar
> initiative.
> >> * JPMorganChase: Derek LaSalle (derek.n.lasalle@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@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@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.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this mail list, you must leave the OASIS TC that
> >> generates this mail. Follow this link to all your TCs in OASIS at:
> >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.ph
> >> p
> >
> >