Musings, but not yet Conformance on dtStart, Duration, and dtEnd, with a

Musings, but not yet Conformance on dtStart, Duration, and dtEnd, with a little bit of UTC thrown in.

I have gathered the issues below into a single collector because they are all dancing around the troika of dtstart, duration, and dtend.

From the conversation on Friday:

- All three must be legal everywhere.

- You only need two out of three

- Anyone sane (or at least with a modicum of scars) records all three in his database to allow searching, filtering, etc.

- Best practice is to record the start and end in UTC as well as in TZ, and note which form the request came in.

Other vobjects. Differ from each other largely in their conformance rules. Vtodo normally has only a dtEnd. Alarms normally have a dtStart.

Precedence issues:

- If we allow all three, there is no guarantee that the combination is valid (I want a duration of two hours beginning at 9:00 and ending at 10:00)

- For planning purposes, duration must take precedence. Duration maps better to granularity.

Is there a semantic difference? If I specify dtEnd, am I say “finish on or before?” If I specify dtStart, am I specifying start on or before?

If I specify durations, then sequences are pre-definable and invocable. If I put either of the dt’s in an interval in a sequence, then that sequence is not re-locatable. That prevents re-use. Is this conformable? Should we conform that Intervals in a Sequence must not have dtStarts, only durations, and the start (or end) must come from a gluon?

Is conformance tied to transactive state? A tender in EMIX might need to be all Durations, but a report / history may naturally flow to dates.

Can intervals in a historic sequence have only dtEnds? Only dtStarts? Allowing this means that intervals are meaningless unless one has the whole sequence.

Please discuss.

The issues:

Key	Summary
WSCALENDAR-448	All - Does the standard assuming any type of industry? Specification of interoperability for the energy industry is lacking. Certain assumptions will leave the interoperability more difficult and costly, rather than generic.
WSCALENDAR-441	Section 3.1.1 - Choosing one format would benefit interoperability.
WSCALENDAR-434	Section 2.2.1 - "no representation as whether UTC or local time are more appropriate " - A hard decision here would have provided lots of benefit to interoperability. Flexibility will not help with interoperability.
WSCALENDAR-431	All - The standard provides every possible method to define intervals and schedules while this is clever it does not increase the chance of interoperability.
WSCALENDAR-429	Table 1.6 - The definition relate to implementation e.g. "need inheritance" or "not complete" rather than the information that is undefined in this state
WSCALENDAR-426	Abstract - If there is nothing energy sector specific in this standard what benefit does it provide over the other standards mentioned.
WSCALENDAR-423	All - the standard does not effectively address the time period definitions that are particular to the wholesale energy markets
WSCALENDAR-420	Line 2678 - "Intervals SHALL NOT include an END time."
WSCALENDAR-364	Line 887 - Uid, Summary, dtStart, dtEnd, duration, and Granularity
WSCALENDAR-357	Line 858 - dtEnd says "SCHEDULED completion time..." is this implied or computed or expressed? dtStart simply says "Start time"
WSCALENDAR-356	Line 858 - dtEnd is not listed and optional, as are dtStart and duration (DtStart and Duration?)
WSCALENDAR-350	Line 368 - Elsewhere it's recommended that intervals have DtStart and Duration (either of which can be filled in through eg inheritance), but we see later an odd blend (line 858 adds DtEnd to the mix). This needs to be clear and consistent across the doc.
WSCALENDAR-348	Line 368 - Both DtStart and Duration are "optional". What precisely does that mean? That neither need to be present? we find later that these values can be inherited from a gluon, but at this point "optional" seems to mean "no value is required"
WSCALENDAR-281	Line 858 - it is unclear why there is a restriction on using only dtStart and duration, and dtEnd and duration, but NOT dtStart and dtEnd.

“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