Re: terminology was Re: Model draft

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

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 need to be clearer about LFB components.  You say
> "Note that we often refer to LFBs without distinguishing between an LFB class
> and LFB instance when we believe the implied reference is obvious for the given
> context."
>
> but I am not quite there yet:-(
>
> Is this an LFB Class you are referring to?  If so, then an LFB Class is, from
> the XML, quadrapartite; ports, events, components and capabilities.  The last
> two have componentId attributes, the first two do not, so I am seeing the first
> two as not Components but just another part of the LFB Class; although saying
> that, events have eventId attributes which are like componentId but not enough
> the same.
>
> Do you agree?
>
> (And yes, for all its 200,000 words, English is bit short in that deparment).