See below Too late to put in 1.0 (unless we have some other compelling reason to re-do) but definitely a section for 1.1… tc "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you." - Fredrich Nietzche Toby Considine TC9, Inc TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Email:
Toby.Considine@gmail.com Phone: (919)619-2104
http://www.tcnine.com/ blog:
www.NewDaedalus.com From: Robin Cover [mailto:
robin@oasis-open.org] Sent: Saturday, July 02, 2011 1:35 PM To: Toby Considine; Toby Considine Cc: Chet Ensign; Robin Cover Subject: iCalendar/WS-Calendar - inconsistencies in existing standards Toby, With respect to the "compatibility issues" [1] between iCalendar and (evolving) WS-Calendar, you ask: > How / where should we call them out in the spec? > What is the preferred manner / section / whitepaper to discuss these issues? > potential Interop issue... IMO, creating a White Paper would be overkill: too slow, too much admin bureaucracy, and otherwise just not the right solution. Besides, you might have to wait for 18 months for TC Admin to send you White Paper template. ;-) Let's take a page from IETF, experimentally, per below. I suggest that you create a new document Section in WS-Calendar (and/or other spec) with the title: "Interoperability Considerations" Put this new section immediately before the required Conformance section, imitating IETF style of putting this kind information ("Security Considerations", "IANA Considerations") near the end, before annexes. ****** Example: load up this spec
http://tools.ietf.org/id/draft-ietf-httpstate-cookie-18.html a) Notice the (typical) IETF section "Security Considerations"
http://tools.ietf.org/id/draft-ietf-httpstate-cookie-18.html#security-considerations b) But similarly here: Privacy Considerations
http://tools.ietf.org/id/draft-ietf-httpstate-cookie-18.html#privacy-considerations c) And also here: Implementation Considerations
http://tools.ietf.org/id/draft-ietf-httpstate-cookie-18.html#implementation-considerations ****** For WS-Calendar, add a new section with title "Interoperability Considerations" and create the content you need to call out the potential for better alignment, clear interop guidelines, future liaison work, etc. It will be of good service to the implementers. Excellent idea to present this information! Other examples of how IETF uses these kinds of final document sections to call out issues/concerns/qualifications.
http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-31#section-8 http://tools.ietf.org/id/draft-jones-json-web-token-00.html#Security - Robin [1] [Toby said] There are a few compatibility issues that are already known in ws-calendar. How / where should we call them out in the spec? 1) Duration: XSD and Icalendar implement different subsets of iso8601. XSD does not implement Weeks (P1W), iCalendar does. Icalendar does not Months or Years, XSD does. WS-Calendar would like to use both. 2) Timezones. XSD got it wrong. If I knew how to use 1.1 facets, I would constrain XS:datetime to the 'no timezone' approach. 3) WS-Calendar does not do less than seconds. XSD can. Potential Interop issue. What is the preferred manner / section / whitepaper to discuss these issues? tc On Fri, Jul 1, 2011 at 3:09 PM, Chet Ensign <
chet.ensign@oasis-open.org > wrote: Toby, Yikes - apologies that I didn't give you an answer sooner! However, bottom line is "up to the TC." Given the importance of keeping WS-C aligned with iCal, you may want to address this in a future version in a separate section of the WS-C specification. I don't recall from my initial walk through, but if you say in the beginning that WS-C is meant to be a conformant implementation of the iCal spec (or something equivalent -- I seem to recall that you do) then adding a Know Issues section to the spec would be logical. Alternatively, you could draft these as a Committee Note. They are more like guidelines on implementation than they are part of the spec itself so that would be fine too. Whichever makes logical sense to you. Robin may know of other instances where similar work has been done but I don't know of any. Best, /chet On Thu, May 12, 2011 at 5:54 PM, Toby Considine <
Toby.Considine@gmail.com > wrote: There are a few compatibility issues that are already known in ws-calendar. How / where should we call them out in the spec? 1) Duration: XSD and Icalendar implement different subsets of iso8601. XSD does not implement Weeks (P1W), iCalendar does. Icalendar does not Months or Years, XSD does. WS-Calendar would like to use both. 2) Timezones. XSD got it wrong. If I knew how to use 1.1 facets, I would constrain XS:datetime to the “no timezone” approach. 3) WS-Calendar does not do less than seconds. XSD can. Potential Interop issue. What is the preferred manner / section / whitepaper to discuss these issues? tc “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. Toby Considine TC9, Inc TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Email:
Toby.Considine@gmail.com Phone: (919)619-2104
http://www.tcnine.com/ blog:
www.NewDaedalus.com -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society
http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:
http://linkd.in/OASISopen Twitter:
http://twitter.com/OASISopen Facebook:
http://facebook.com/oasis.open -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email:
robin@oasis-open.org Staff bio:
http://www.oasis-open.org/people/staff/robin-cover Cover Pages:
http://xml.coverpages.org/ Newsletter:
http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783