OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-calendar message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: My summary from WS-Calendar 20110715


Gershon -

I'm sending the chat notes separately to just you and Toby; I typed in most of the discussion. We went on for a total of 90 minutes.

Toby and all --

Ditto...

Sending to the list as my summary for further discussion.

I mentioned my discussion with the synchrophasor folks about time synchronization at Montreal.

We discussed the issue Mike had raised (small schema change, no effect on artifacts) and seemed to be mostly interested in 1.1 (or 1.0.1 if urgent) - it's for timezone server implementation, not consumption of timezones.

I brought out the name duplication and the effect on artifact size; the conclusion was that a small XSLT transform could take care of it, and that could be 1.0.1 or later. The discussion (see chat) was around simple software versus maybe smaller (maybe not) artifacts and the bias toward simpler software. We need the uses to conform, and a transform in front may well be just fine.

We then discussed the one ws-calendar-comment comment (Frances and Marty). The consensus, but not formally voted, was to no change the request but show how to work it in (e.g.) energy interop where randomization could be expressed as required in Standard Terms. 

The fuzz interval is already defined with startbefore/startafter performance, and the Standard Term in an application would be "randomize with the following distribution over the startbefore+startafter duration, centered as indicated by the start time. So the information model doesn't change, and the "randomize over that interval" would be done operationally and known by the sender and recipient.

I'm not happy with the economic issues, and this randomization trashes actionable information requirements (who pays for time before and after? the market sold for this time, and had better not randomize). The semantic issues are very thorny.  Likewise for DER/Curtailment requests where there is an economic impact - in effect the 61850 approach (which their comment extends - 61850 says "randomized over interval" not "randomize with a uniform distriution over interval", so this is above and beyond) ignores economics and centers ONLY on reliability.

The conclusion is to show how to do this in energy interop as an example in the comment response.

Thanks!

bill
--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]