Capabilities and Performance in WS-Calendar

["Toby Considine" <Toby.Considine@gmail.com>]

We have discovered numerous attributes that are relevant to service performance using WS-Calendar. These include ramp time, accuracy, precision, something we haven’t named (What is more important: Begin Time, End Time, or Duration). One could argue that these are irrelevant to WS-Calendar and they should be built into the referenced services. I think this is wrong because these characteristics are common to just about any scheduled service.

 

Simplifying the conversation, let’s assume that all WS-Calendar things are VTODO objects. Let’s imagine a <PERFORMANCE /> component that somehow includes all of the above features and perhaps some more. There are two ways that it might be useful to put this together, CalConnect willing….

 

(1)    Optional item in a VTODO object

(2)    Optional Item in Components section of WS-Calendar object

 

A key design constraint is that existing calendar systems must be able to consume, ignore, and still emit any extensions. If <PERFORMANCE /> is transmitted using the XCAL format  to an existing Exchange or Beehive server, it will be not understood and ignored. The text string of the XML, though, will be stored in the server, and can be reconstituted into the original event if request requires that a new XCAL object be generated.

 

I am proposing first, that the VTODO object accept the performance component

 

(individual performance model)

<vtodo>

<duration />

<attachment />

<performance />

</vtodo>

 

I am proposing second that we accept a performance object outside the VTODO, but inside the components. Components is the section inside iCalendar that holds the Vobjects.

 

(aggregate performance model)

<components>

<performance />

<vtodo>

<duration />

<attachment />

</vtodo>

<vtodo>

<duration />

<attachment />

</vtodo>

<vtodo>

<duration />

<attachment />

</vtodo>

<vtodo>

<duration />

<attachment />

</vtodo>

<vtodo>

<duration />

<attachment />

</vtodo>

</components>

 

In the aggregate performance model, all VTODO objects are subject to the same constraints.

 

QUESTIONS:

 

1)      CALCONNECT: Are either of these models acceptable to the XCal crowd.

2)      OASIS/ENERGY: I can think of lots of use cases for the Aggregate model. DO we need the Individual model

 

A significant case I am thinking of would allow the attachment object into performance as it is in VTODO, defined an energy contract to apply to a whole sequence of consecutive times, put the primary contract into the aggregate, and use the individual slices/VTODOs for a quantity only.

 

 

Conversations welcome

 

tc

 

---

“It is difficult to get a man to understand something, when his salary depends upon his not understanding it” -- Upton Sinclair.

---

Toby Considine TC9, Inc OASIS Technical Advisory Board 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