Re: miscellaneous comments was Re: Model draft

["Joel M. Halpern" <[e-mail]>]

Thanks.  Comments where further clarification helps / is needed.
(Exchange is between Tom Petch and myself.  Headers removed as there are
only two conversants.)

tom.petch wrote:
> Joel
>
> cutting the ones I think we agree on, comments in line
>
> Tom Petch.
>
>

>>> 4.7.3.  <outputPorts> Element to Define LFB Outputs
>>>    This is indicated by a "yes" value
>>>    (the default value is "no").
>>>
>>> **+ The XML has default of 0 - I see no indication which is yes and which
> no;
>>> some XML users define a truthValue, of yes or no.
>> Not sure what you are asking for.  The attribute definition says that
>> the attribute is optional and has a default of "no".  Folks have run
>> this through XML vereifiers and it seems okay.
>>
>
> What I am looking at in the Schema is
>  <xsd:simpleType name="booleanType">
>         <xsd:restriction base="xsd:string">
>           <xsd:enumeration value="0"/>
>           <xsd:enumeration value="1"/>
>         </xsd:restriction>
>       </xsd:simpleType>
>
> from which I cannot tell whether you intend 0 means true or 0 means false, so
> syntactically valid but semantically ambiguous to me.  I am used to both in
> other languages and prefer the XML-Schema approach which allows, to quote
>
> 3.2.2.1 Lexical representation
> An instance of a datatype that is defined as .boolean. can have the following
> legal literals {true, false, 1, 0}.
>
> so using true and false is - to me - clearer.

Arggg.  I thought we had cleaned up all those inconsistencies.  I will
go check and make it consistent.  Probably using true / false, but I
need to review what we did elsewhere because the most important goal is
consistency.

>
>>>
>>> 4.7.4.   <components> Element to Define LFB Operational Components
>>>    The <component> element also MUST have an componentID attribute,
>>>    which is a numeric value used by the ForCES protocol.
>>>
>>> **+ The XML allows this to be a negative integer; is this intended?? ditto
>>> eventid
>> No, it is not acceptable for IDs to be negative.  Is there a standard
>> XML schema datatype for non-negative integer?  Or do I have to define a
>> simple subrange myself in the document?
>>
>
> Um, this has thrown me.  What is uint32? I had taken it to be unsigned integer,
> like the XSD unsignedInt and so ranging from 0 to 4Gig.  XSD defines short, int,
> long and unsignedshort, unsignedint, unsignedlong and I tend to take these for
> granted.

Your right, all I need is to switch those to uint32.  My mistake.

>>>    4.7.6.1.  <eventTarget> Element
>>> **+ must <eventTarget> reside in the same LFBClass definition as the event
>>> definition??
>> Yes, eventTarget must be a field in the LFB in which the event is
>> defined.  All the reporting parts must also be in that LFB (although not
>> necessarily in the same component as the eventTarget.)  I do not expect
>> the schema to capture this constraint.  I thought the event text covered
>> this.  Please look again.  If it is not covered, I would appreciate
>> suggestions as to how to make it clear.
>>
>
> It was rather that I was seeing this as a constraint, that in a large and
> complex system, one approach would be to split by type, to have all the
> datatypes in a module, all the frametypes in another and to split events from
> components, but this last is not allowed.  I worked this out from the XML, from
> naming scopes, so I am not sure that it is explicitly stated in this secton

I think it is explicitly stated.  Events are (I would say MUST be, but
it is even more intrinsic than that) defined as part of the LFB
definition.  Unlike data structure definitions, they can not be factored
out and referenced.
Part of the reason for this is that it seemed to me (and others when we
were working on it) that different contexts will want different events,
even for data of the same type.

>>>
>>>                   <name>threshold</name>
>>>                   </optional
>>>                   <typeRef>uint32</typeRef>
>>> **+ again curious why uint32 as it excludes a negative threshold??
>> I started writing a defense of this.  Then I realized that it is mostly
>> just that we didn't think about the case of a signed value.  The main
>> problem I have now is that if I define it as signed, how does a CE
>> specify a large (2^31 or more) threshold for an unsigned field?
>> Suggestions?
>>
>
> As above, I tend to take the XSD basic types of (unsigned)short, int and long
> for granted, the last allowing for 64bit

In this case (unlike the element ID above) that doesn't help.  The
thresholds value is not an XML value at all.   It is a Forces data type
value.  And the threshold may be for use with a signed or unsigned
element.  So I am not sure what the right way to define the threshold
itself is.  My temptation is to leave the definition as uint32, and note
that if applied to a signed value, it will be interpreted by the FE as a
signed quantity for comparison purposes.  Ugly, but at least well
defined.  I would like something better.

>
>>> 8.4.  Events
>>>    If a laser oscillates in power near the 15 mark, one could get a lot
>>>    of notifications.  (If it flips back and forth between 9 and 10, each
>>>    flip down will generate an event.)
>>>
>>> **+why should oscillation between 9 and 10 generate any events? around 15
> yes,
>>> but I do not see the relevance of 10 and 9
>> That should be 14 and 15, not 9 and 10.
>>
> good:-)  If the threshold is 15 precisely and the value fluctuates betwen 15
> precisely and lower values, then will that generate multiple events? ie are we
> talking strictly greater than, or greater or equal to?  or is that a corner case
> to leave up to implementers? I am easy either way.

If hysteresis is not specified for the event, then a detectable
oscillation near the threshold will produce a cascade of events.  That
is mandatory, which is why the hysteresis is so important.


Yours,
Joel