Re: terminology was Re: Model draft

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

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








> Yours,
> Joel
>
> tom.petch wrote:
> > ----- Original Message -----
> > From: "Joel M. Halpern" <[e-mail]>
> > To: "tom.petch" <[e-mail]>
> > Sent: Wednesday, January 02, 2008 2:59 PM
> > Subject: Re: Model draft
> >
> >
> >> I can well believe that the terms as used in S1 could be clearer.
> >> I have no problem trying to clean up hierarchy, layer, abstraction, and
> >> level.  I'm not sure it will help much, but I am willing to try.
> >>
> >
> > Joel,
> >
> > let me start again on terminology
> >
> > I think that the change is terminology is excellent, much easier to follow.
> > Back in August, you posted to the list that you would come back with how
many
> > new terms you needed, but I missed - and perhaps miss - that.
> >
> > I think the new terminology does show up some inconsistent usage, and yes I
will
> > propose text, but need to understand more first.  (I find
> > myself having to reverse engineer the XSD in order to understand the text,
and
> > that should not happen:-) .  s.4 is easier to follow, for all its level of
> > detail, than the overview in s.3 and again, I think that this should not
happen.
> > I do see a value in being able to read and understand s.3 and not needing to
go
> > further, whereas if you need the level of detail in the whole document, then
> > yes, you will put in as many weeks as it takes and will get there.
> >
> > I am referring to the terms: capability, capacity, component, configuration,
> > operational, state.
> >
> > Thus, to quote some usage, which I see as in conflict,
> >
> > s1 operational parameters in LFB Component
> > 2.1 operational capabilities, configurable parameters (ie attributes)
> > 3 capability and state model
> > capabilities and capacities
> > 3.2.6 LFBs are made up of components
> > Fig 1 capability FE->CE configuration CE->FE
> > 4.7 capability components, operational components
> > 4.7.4 LFB Operational Components (are) Operational parameters
> > 4.75. capability components
> > 5 FE components and capabilities
> >
> > I think that component is what most needs nailing down, and that s.4 is
clearest
> > with capability components and operational components and that elsewhere the
> > meaning of component is flexible, too much so.
> >
> > I would like to define Component (and yes, I think that capitals matter) as
> >
> > "an addressible unit of information in the ForCES protocol that may be read
and,
> > in some cases, written; it may be an atomic data type or a complex data
> > structure which in turn may contain further ForCES Components.  A Component
has
> > a 32-bit ID, name, data-type
> > and a synopsis.  The XML elements <component> and <capability> are both
> > Components in this sense."
> >
> > If you don't define Component as both <copmponent> and <capability>, well
then I
> > think you will have to create another term that means just that.  By
defining
> > Component as both, then you can easily and clearly pick out one or the other
as
> > Capability Component or Operational Component.
> >
> > Does that accord with your intentions?  If not, then please suggest a
different
> > definition.
> >
> > Tom Petch
> >
> > "When I use a word, it means what I want it to mean" Humpty-Dumpty
> >
> >> However, I have no idea what you want us to do with section 3.2.6.
> >>
> >> To put it differently, I agree that the intro should be clearer.  But I
> >> presume that by the time you have read the document, you can figure out
> >> what you think it is trying to say.
> >> At this point in the life cycle, it is really very helpful if we have
> >> specific suggested text.
> >>
> >> Yours,
> >> Joel
> >>

<snip>