There is no setOwner as such in th espec. owner is an attribute. Typically that is a read-only attribute changeable only indirectly (through move/rename maybe) or by a superuser through some out of band approach. (linux chown). What IS missing is some language to describe read-only and read/write properties - or just a terse read-only indication for those properties that cannot be explicitly set - owner, lastmod, created etc, As for splitting it - WsCalendar defines how to use icalendar entities to represent certain actions and behavior. It's not protocol dependent (and shouldn't be) so splitting the protocol from the spec makes sense. In fact CalDAV itself (those implementations that support XML in calendar) or simply storing the stuff in a file might be adequate for some implementations. I think this gets closer to Bill's PIM? thing. CalWS-REST and CalWS-SOAP could stand alone as generic calendaring protocols - CalConnect already published the standalone version or CalWs but it needs the OASIS stamp to turn it into a standard. The documents might be WsCalendar - an extension to iCalendar CalWs-REST CalWs-SOAP WsCalendar over CalWs-SOAP etc. The last document can specify exactly which functions are used and how they are used to achieve the aims of WsCalendar. On 05/19/2011 08:34 AM, Toby Considine wrote: 000f01cc1621$0c9a6a80$25cf3f80$@gmail.com type= cite > WS-Calendar has two parts, an Information Model (w/ associated schema) and a communication portion (describing SOAP and RESTful interactions with Calendar Services). Part 1 is likely done, ready for a final Public Review Part 2 might need a while longer Comments to date have suggested some readers feel that they cannot use part one unless they commit to the specific functions in parts 1&2. An instance of this is the RESTful interaction has a setOwner method (for security, and extending a long existing CalDAV method) that a smart energy company believes causes them regulatory heartburn as it could only mean changing ownership and liability for generation <sigh /> If the TC votes to split it into two parts at Friday’s meeting 1) What would that vote need to look like 2) Is there an recommended naming pattern for the two parts in OASIS 3) What procedurally would we need to do to release a PR03(a) for potential vote as a CS, while working on PR03(b) for longer while the interactions are being tested? Thanks 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 Spam Not spam Forget previous vote -- Mike Douglass
douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180