ws-calendar — archive

[Toby Considine]

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