Good conversation this week. As you will see presently in WD08, I was able to reduce portions of the document, reflecting the reduction in complexity of the terminology and the data structure.
I think that with this change, we are close to feature complete in the non-service portions of the specification. More re-writing for clarity will be required.
In any case, this is what I sent CalConnect
"If something is not worth doing, it`s not worth doing well" - Peter Drucker
From: Toby Considine [mailto:Toby.Considine@gmail.com]
Sent: Saturday, August 07, 2010 5:52 PM
To: 'tc-xml-l tc-xml-l Reflector'
Subject: Performance Attributes
Last week I posited a Performance object among the components. This weekend I have fleshed it out in latest Working Draft (WD08) of WS-Calendar.
There are two models the draft currently supports.
(1) Each vObject may include a Perfomance object.
(2) A single performance object may be included in the performance section. If so, that performance object applies to all components .
My goal here is to create a single extensible XML artifact that can both define the performance expectations and can be easily excluded in accord with the rules, as I understand them, for processing xCal.
I need feedback on that original idea. I also invite feedback on the naming of each of the elements within the Performance component.
Performance Characteristics of Time Segments
Each interval, or each collection of intervals, i.e., each sequence or partition, MAY be associated with a Performance component. The performance component defines the expectations of the calling process abut service performance. Service coordination between systems requires that expectations about the timeliness of performance be communicated precisely.
these as in a Sequence
An interval can have many further refinements of time-related performance communication. There may be requirements of required precision. Minimal notification before performance may be specified.
For service to service communications, WS-Calendar communicates these expectations precisely. A timely response may be within a few minutes of the target time, or it may require Tolerance in milliseconds. As defined by the W3C,
“All minimally conforming processors must support year values with a minimum of 4 digits (i.e., YYYY) and a minimum fractional second precision of milliseconds or three decimal digits (i.e. s.sss). However, minimally conforming· processors ·may· set an application-defined limit on the maximum number of digits they are prepared to support in these two cases, in which case that application-defined maximum number ·must·be clearly documented.”
Time Segments are a necessary component of all specifications derived from or incorporating the WS-Calendar specification. The base iCalendar object for all time segments is the VTODO object as expressed in the xCal serialization. Some additional fields for precisions and performance management are defined
Table 2: Performance Characteristics
Performance Characteristic | Definition | Discussion |
StartBeforeTolerance | A Duration enumerating how far before the requested start time the requested service may commence. | Indicates if a service that begins at 1:57 is compliant with a request to start at 2:00 |
StartAfterTolerance | A Duration enumerating how far after the requested start time the requested service may commence. | Indicates if a service that begins at 2:01 is compliant with a request to start at 2:00 |
EndBeforeTolerance | A Duration enumerating how far before scheduled end time may end. | Indicates if a service that ends at 1:57 is compliant with a request to end at 2:00 |
EndAfterTolerance | A Duration enumerating how far after the scheduled end time the requested service may commence. | Indicates if a service that ends at 2:01 is compliant with a request to end at 2:00 |
DurationLongTolerance | A Duration indicating by how much the performance duration may exceed the duration specified in the Interval . It may be 0. | Used when run time is more important than start and stop time. SHALL not be used Start and End Tolerances are also specified. |
DurationShortTolerance | A Duration indicating by how much the performance duration may fall short of duration specified in the Interval . It may be 0. | Used when run time is more important than start and stop time. SHALL not be used Start and End Tolerances are also specified. |
Attachment | If all Intervals in Sequence or Partition concern a similar contract, then a single Attachment may define that contract for all. Attachments are defined in section 3.2.6 (Attachments) | An example of the use of an attachment would be an energy delivery contract with a price that varied per Interval cross the Partition. |
Granularity | A Duration enumerating the smallest unit of time measured or tracked | Whatever the time tolerance above, there is some minimum time that is considered insignificant. A Granularity of 1 second defines the tracking and reporting requirements for a service. |
Note that because performance characteristics are all, except Attachment, Durations, none of specified a particular date or time for performance. Similar products with different performance characteristics may be offered to the markets prior to scheduling. Performance characteristics influence the price offered or the service selected. It is only when scheduled for performance that performance characteristics actual times can be derived from the scheduled start time.
Example 1: Performance Component
<performance>
<startbefore>T00:10</startbefore>
<startafter>T00:00</startafter>
<durationlong>T00:00</durationlong>
<durationshort>T00:00</durationshort>
</performance>
In the example, the service can start as much as 10 minutes earlier than the scheduled time, and must start no later than the scheduled time. Whenever the service starts, it must be performed for exactly the duration indicated.
“It is difficult to get a man to understand something, when his salary depends upon his not understanding it” -- Upton Sinclair.