Re: miscellaneous comments was Re: Model draft

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

Joel

cutting the ones I think we agree on, comments in line

Tom Petch.


----- Original Message -----
From: "Joel M. Halpern" <[e-mail]>
To: "tom.petch" <[e-mail]>
Sent: Saturday, January 05, 2008 4:32 AM
Subject: Re: miscellaneous comments was Re: Model draft


> Response to questions in line.
>
> tom.petch wrote:
> > Some comments, prefixed with **+, that do not relate to terminology:-)
> >
> >

> >
> > **+ is this an XML import or XML include or both or neither? (this has
> > implications on namespaces)
> This is neither an XML import or an XML include.  It is an LFB library
> import, <load>  It makes a set of definitions available to the entity
> processing the library, both as classes (if any) and as types, etc.
> This would primarily be done to make sure that datatypes (including
> metadata) that are being used, or strctures or LFB classes that are
> being extended / revised are available.
>
> It can be argued that we should have used an XML level import, and that
> we could then specify certain semantic constraints in the Schema that we
> currently have only as comments / normative constraints in the text.
> But given that there will always be some constraints we can not capture
> in the schema, this did not seem to be a big issue.  And it was much
> simpler to avoid getting into XML imports.
>

Yes, makes sense:-)


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

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

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

 > >             <dataTypeDef>
> >               <name>eventElementProperties</name>
> >               <struct>
> >                   <typeRef>uint32</typeRef>
> > **+ curious why registration of an event is not boolean??
> I went back and forth on whether to make this a boolean.  it is an int
> to allow for future cases where we may want to allow notifications to
> multiple CEs, even if there is only one manager.  At the moment, that is
> too complex to add.  But it seemed simple to allow for it now.  If it
> bothers folks, I can remove it.  (But I would prefer to leave it alone.)
>

Yes, leave alone, just my curiosity

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

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

> >
> > Tom Petch
> >
>
> Thanks Tom.  I am very glad someone is reading this carefully.  I will
> get these fixes (except where I specifically ask for help) into the
> document.
>
> Yours,
> Joel