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
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 -->
<xs:element name="currentLevel"
type="eitc:CurrentLevelType"/>
<xs:complexType name="CurrentLevelType">
<xs:annotation>
<xs:documentation>Current Value reprises
what the Signal Level is at the moment EventInfo is
created.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element ref="eitc:signalLevel"
minOccurs="1" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
In wd29-wip2 the SignalLevelType is (largely) an xs:choice:
<xs:complexType
name="SignalLevelType">
<xs:annotation>
<xs:documentation>The Signal Level is a
Stream Payload holding a single
value.</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension
base="eitc:StreamPayloadBaseType">
<xs:sequence>
<xs:choice minOccurs="1"
maxOccurs="1">
<xs:element
ref="eitc:signalDelta" minOccurs="0" maxOccurs="1"/>
<xs:element
ref="eitc:signalSetpoint" minOccurs="0" maxOccurs="1"/>
<xs:element
ref="eitc:signalPercent" minOccurs="0" maxOccurs="1"/>
<xs:element
ref="eitc:programLevel" minOccurs="0" maxOccurs="1"/>
<xs:element ref="emix:quantity"
minOccurs="0" maxOccurs="1"/>
<xs:element ref="emix:priceBase"
minOccurs="0" maxOccurs="1"/>
<xs:element
ref="emix:productDescription" minOccurs="0"
maxOccurs="1"/>
<xs:element
ref="eitc:applicationSpecificSignalBase" minOccurs="0"
maxOccurs="1"/>
</xs:choice>
<xs:element ref="emix:itemBase"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
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//
6)
CurrentValue is now CurrentLevel, an enumerated set of
elements (choice, 1 per instance) to handle levels,
prices, setponts and even application specific info
Ed>
Why did you change the name??? You seem to have defined
it in a way that is different than its intended
semantics. Also why did you change signalLevel to
programLevel? I don't agree with this name change.
Tc>>>I am not wedded to this name, but
there is something more important going on under the
covers. We now have an whereas before is contained
only a single number, now it contains exactly the same
object/set of choices that is potentially in each
signal interval. Conformance statements will state
that the same choice be made in each Interval in the
stream and in the Current*** if present..
The semantics in WD29-WIP2 (and in the proposed
chapter 4, also posted yesterday) is that Each
Interval, and the Current*** if present, contain a
Signal Payload. The conformance in the Spec says that
all Signal payloads in a given Signal be the same,
i.e., every one is a Price, or every one is a program
level, or every one is an EMIX, or every one is a
setpoint…. This was part of creating the consistent
pattern for all Streams-derived objects. My plan is
that we will use the same semantics for Baselines and
for Feedback, including the many Steffes feedbacks.
See (7, 8)
//snip//