Re: miscellaneous comments was Re: Model draft

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

Response to questions in line.

tom.petch wrote:
> Some comments, prefixed with **+, that do not relate to terminology:-)
>
>
> 3.2.   Logical Functional Block (LFB) Modeling
>    An LFB can have one or more inputs, each of which takes a packet P,
>    and optionally metadata M; and produces one or more outputs, each of
>    which carries a packet P', and optionally metadata M'.
>
> **+ I think that this is too restrictive; s3 says that output may be metadata
> only.
Yes, this text is too restrictive.  There are multiple cases of input or
output where the "packet" is empty.  I have to think whether it is
better to refer to a conceptually empty packet, or an omitted packet.
(The reason it doesn't matter much is that this kind of case has to be
called out in the descriptive portion of the LFB definition, so the only
question is how we describe it.)
>
>
> 4.2.  <LFBLibrary> Element
>    In addition to the above main elements, a library document can import
>
> **+ 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.

>
>
> 4.5.4.  <struct> Element to Define Structures
>    In
>    addition, the component declaration contains the name of the
>    component, a synopsis, an optional description,
>
> **+ I see no <description> in the XML for <component> in <structType> but one is
> present in <LFBComponentsType> ; is this intended?
This is an error.  We should have a <description> element allowed in
<structType> component definitions.

>
>
> 4.5.6.  <alias> Element
>    The target of a component declared by an >alias> element is
> **+ <alias>
>
>
>     Details of the alias property structure are described in the section
>    of this document on properties.
> **+ suggest making that explicit ie section 4.8
If you are asking "please put in a numberic section reference", that is
a good idea.

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

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

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

>
>
>  **+/componet/component/ in the LFB.
>
>
>             <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.)

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

>
>
>
> 4.8.5.2.   Event Hysteresis Filtering
>       again until the field first becomes less than or equal to T - -V,
> **+ /T - V/ ??
Thanks, there is indeed a redundant minus sign there.

>
>
>
> 4.8.6.  Alias Properties
>           <dataTypeDef>
>             <name>aliasElementProperties</name>
>                 <synopsis>
>                   the path to the component target
>                   each 4 octets is read as one path element,
>                   using the path construction in the PL protocol.
>
> **+ suggest adding a ref to the protocol RFC
I suppose we should.

>
>
> 5.  FE Components and Capabilities
>    Only one instance of
>    this class will ever be present, and the instance ID of that instance
>
> **+ suggest adding 'in an FE'
Fair enough.

>
>
>    Details of that class are defined in the ForCES protocol
>    document.
> **+ suggest adding a reference to the protocol RFC
Well, since we have to add the reference above, we might as well use it
here.

>
>
> 5.1.   XML for FEObject Class definition
>                   <component access="read-only" componentID="7">
>                     <name>FEState</name>
>                     <synopsis>model of this FE</synopsis>
> **+ this synopsis does not look relevant for FEState
Thanks.  That is the wrong synopsis.

>
>
> 5.3.1.  FEStatus
> **+ the element is <FEState> not FEStatus but the type is FEStatusValues - mmmm
I'll clean it up, one way or the other.

>
>
> 7.5.  State Query of LFB Attributes
>       This is primarily to refer to a single
>       FE, but referring to a group of (or all) FEs may
> **+ suggest /optional/optionally/ be supported.
Ack.

>
>
> 8.  Example LFB Definition
>    While some
>    properties of LFBs are shown by the FE Object LFB, this endeavors to
>    show how a data
> **+/plain/plane/??
Ack.

>
>
>             <dataTypeDef>
>               <name>PortStatusValues</name>
>               <synopsis>
>                   The possible values of status.  Used for both
>                   administrative and
> **+ suggest /operation/operational/ status
Ack.

>
>                   <specialValue value="1">
>                     <name>Enable</name>
> **+Enabled?? Enable is used in 8.1.1 but seems odd in contrast to Disabled
>
>                     <synopsis>FE is operatively disabled</synopsis>
> **+ /disabled/enabled/  ??
Probably should be Enabled rather than Enable, and indeed Enabled in the
synopsis.

>
>
> 8.1.  Data Handling
>    the LFB **+/too/to/ look up
Ack.

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

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