Procedural Advice

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

“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

ws-calendar message