Re: miscellaneous comments was Re: Model draft

["tom.petch" <[e-mail]>]

All ok with me.

The only other thought I have is with threshold for events where you could
specify a type of character string rather than uint32 leaving the user to coerce
the string into a number as appropriate.  Representing numbers as strings always
seems clumsy to me but I think of it here because the XML canonical
representation is a character string.

Tom Petch


----- Original Message -----
From: "Joel M. Halpern" <[e-mail]>
To: "tom.petch" <[e-mail]>
Sent: Monday, January 07, 2008 11:43 PM
Subject: Re: miscellaneous comments was Re: Model draft


> 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
>
>