[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Cached data in EiEventType (was [energyinterop] RE: wd29 wip2 changes EK item #6) and application data
Bill,
Whatever type we attach to a signal interval should of course be the exact same type that we use for the current value. This only makes sense. We were very comfortable with the SignalInformationBaseType in the previous versions of the schema and have been relying upon it for some time. I'm still somewhat confused about the wd29 wip2 version of the schema, but it seems to use the new concrete type called signalLevelType, which is completely different than what was the SignalInformationBaseType. I'd like to point out that this is at least the 5th or 6th time that someone has re-written the specification for what gets attached to a signal interval. I thought we had it nailed down about 2 - 3 months ago which is what we have been using in the Alliance. I can understand some of the things that Toby did (even if I don't agree with them) to try and rationalize the notion of an interval and streams, but the information that gets attached to a signal interval has nothing to do with that exercise and in my opinion should not have been re-written. We were fine with it the way it was and would like to continue using the old SignalInformationBaseType. If for some reason someone wants to add the new attributes and structures that are in the new signalLevelType I must insist that they do it as an extension to the previous version, not supplant it. I thought that was the whole reason to use substitution groups. I also have some problems with the fact that we are now attaching a concrete type to the interval instead of what was a substitution group. Not only does that make the payload bigger, but it seems inconsistent with our pattern for supporting extensibility which was to use substituon groups.
thanks,
-ed koch
From: William Cox [wtcox@comcast.net] Sent: Sunday, October 02, 2011 5:14 PM To: Edward Koch Cc: Toby.Considine@gmail.com; energyinterop@lists.oasis-open.org Subject: Cached data in EiEventType (was [energyinterop] RE: wd29 wip2 changes EK item #6) and application data We added currentValue to the EiEventType as a cache for the current signal value, or (in other words) where the finger of the present time points in the appropriate signal stream.
currentValue in PR02 is an unamed Complex Type and optional. It contains only a SignalInformationBaseType. currentLevel in wd29-wip2 is of type CurrentLevelType and optional. It contains only an eitc:SignalLevelType. In this wip2 the things that are in a signal stream/list are of type SignalInformationBaseType <!-- 6.5.1 Current Value --> In wd29-wip2 the SignalLevelType is (largely) an xs:choice: <xs:complexType name="SignalLevelType"> I have two related questions: (a) Why does each element of the choice have cardinality 0..1? Is this one of those issues around optionality we've hit before on choices? I see that the choice itself is 1..1. (b) Why is an optional itemBase in the choice? That seems odd - a stream/signal stream should be of only one type, and that would allow (e.g.) the first interval to be (say) 7 units of realPower, the second to be 2 units of realEnergy, the third to be 3 of realPower again, and so forh. This doesn't make sense to me. I recommend deleting the itemBase element. I'll pull together the respective UML in another email. Thanks! bill On 10/2/11 11:09 AM, Edward Koch wrote: //snip// //snip// |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]