Re: terminology was Re: Model draft

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

With apologies for bottom posting

Tom Petch


----- Original Message -----
From: "Joel M. Halpern" <[e-mail]>
To: "tom.petch" <[e-mail]>
Sent: Wednesday, January 09, 2008 4:31 AM
Subject: Re: terminology was Re: Model draft


> The ports of an LFB class definition are not "components" in any sense.
>   They are definitions which are referenced by components in the FE LFB
> instance.  The port references are used to provide semantically
> meaningful interaconnect among the LFB instances.
>
> To explain the class / instance distinction a little relative to the use
> of components, the LFB Class definition defines the IDs for the
> components of the LFB.  A structure definition defines the IDs
> components of that structure.
> In the protocol however, what are referenced are actual instances of
> components in actual instances of LFB Classes.  The protocol does not
> ever need to reference an LFB class in the abstract.  The LFB Class ID
> is used for definitional purposes, to indicate what class is being
> referenced when an instances is created or described, and is used to
> help identify the instance as a simple way to create unique IDs.
>
> To return to your trailing question, Events are not actually components.
>   One can not perform a GET or SET on an event.  However, in order that
> the event properties not collide with the properties of actual
> components of an LFB (class or instance), the LFB Class definition
> portion for events assigns a top level component ID to use for them.  To
> allow the protocol to easily refer to the events, the events themselves
> use a second level component ID.  But no, events are not actually
> components.
>
> One aspect that some of your notes touch on.  It is important to
> remember that the entire XML is simply a descriptive technique to allow
> us to document the IDs and their meanings so that they can be used in
> the protocol.  The ForCES protocol itself is not XML.
>
> Yours,
> Joel
>
> tom.petch wrote:
> > From: "Joel M. Halpern" <[e-mail]>
> > Sent: Saturday, January 05, 2008 4:33 AM
> >
> >> I believe that you are correct.
> >> Component includes both <component> (in LFBs and structs) and
> >> <capability> elements.
> >> So yes, you have understood what the document is saying.
> >
> > That's a relief:-)
> >
> >> And yes, what you have written needs to be said somewhere in the
> >> document.  Probably along with fixing some references to become
> >> "Component".  (If I had enough good words, I would just use lower case
> >> component for the english, and have some other words for the LFB and
> >> struct pieces.  But I am all out of words.)
> >> One idea would be to use <component> in the <capabilities> section, so
> >> that there are capability components, other LFB components, and struct
> >> components.  Would that work?
> >>

I think so but I am uncertain about 'other LFB components'; you exclude ports
and events, which agree with, so for me that just leaves the <components> in the
LFBClassDef, which I take to be the operational components of s4.7 (a usage I
like) ie would not operational components be a better term than other LFB
components?

No strong preference, you choose and then I will revisit my boggy areas in the
I-D to see if I can suggest some clearer terminology

And I take your point about this not being XML on the wire, it is something I
tend to forget.

Tom Petch