[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [oasis-charter-discuss] Proposed Charter for OASIS Web Services Calendar (WS-Calendar) TC
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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]