Re: terminology was Re: Model draft

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

[I sent the reply below to Tom earlier today, but could not send it to
the list until now.]

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

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
>>
>> tom.petch wrote:
>>> Much of what I have so far read I like, but I am afraid I still got bogged
> down
>>> as when I got to section 3 with
>>>
>>> "   The ForCES model construction proposed in this document has two major
>>> hierarchies."
>>> ok so the first hierarchy is
>>> "  At the lower layer, "
>>> ok, so no hierarchy but two layers
>>> "an individual LFB class definition  models  distinct manageable feature of
> an
>>> FE.  At a higher "
>>> ah, the other layer
>>> "  abstraction, "
>>> whooops, not layers at all, not hierarchies but abstractions.
>>> "the FE is laid out to constitute many LFB abstractions."
>>>
>>> In fact, I think that these are not layers, not abstractions, not
> hierarchies; I
>>> would say something like
>>> '**The ForCES model has two levels of detail.  The higher - FE - level
> models an
>>> FE as a number of instances of LFB Classes and their topology; the
> lower -LFB -
>>> models the detail of an LFB Class. '
>>>
>>> And, lo and behold,
>>> "capabilities of the FE at a coarse level "
>>> precisely, coarse level (of detail) and fine level (of detail).
>>>
>>> Using four different terms to refer to the same (?) thing makes for a tough
>>> read, too much so IMHO.
>>>
>>> This is section 3, this is overview, so I believe it should be clearer.  And
>>> much of the rest of this section, eg on Capability and State, is by contrast
> so
>>> easy to read, as if it came from a different planet.
>>>
>>> The next swamp that bogged me down is s3.2.6.  Is this LFB Components as
> defined
>>> in s1? If so, then I think that the Capitalisation of Components really
> matters.
>>> And is it only LFB Components? or does this cover Structure Components and
>>> ForCES Components as carefully differentiated in s1?  What you might be
> saying
>>> is that 'LFB Classes are defined in terms of LFB Components'; but then
> again,
>>> you might not be:-(
>>>
>>> But going back to that definition in s1 leads me to a swamp I was in a year
> ago.
>>> LFB Components is defined in terms of 'Operational Parameters'.  How does
> this
>>> relate to 'operational capabilities' and 'configurable parameters' in s2? or
> to
>>> 'capabilities' and 'capacities' in s3?
>>>
>>> It is the same problem for me, if there is a concept, then find a term for
> it
>>> (preferrably one that does not have a different well-defined meaning in a
>>> related sphere:-) and stick religiously to that term and no other.
>>>
>>> And I think that there is another problem in s3.2.6; what is this section
> about?
>>> 'properties' gets used in several places is a general sense; here, out of
> the
>>> blue, comes "The CE needs to know these properties."  What properties?  They
>>> have not been defined or explained - in fact I ended up reverse engineering
> the
>>> XML to find out what this meant:-(.
>>>
>>> I see these changes as a few words here and there, but a big difference in
>>> clarity.  How about you?
>>>
>>> Tom Petch
>>>
>>> ----- Original Message -----
>>> From: "Joel M. Halpern" <[e-mail]>
>>> Sent: Sunday, October 07, 2007 11:27 PM
>>> Subject: Model draft
>>>
>>>
>>>> A revision of the model draft has been submitted to the repository,
>>>> and has been accepted by it.
>>>> Draft -08 repairs the confusion of XML terminology with ForCES
>>>> components, and cleans up a number of other minor terminology items I
>>>> found while doing that.
>>>>
>>>> Further review is likely needed.  Please read and comment.
>>>>
>>>> I have not changed the FE Status information, as I could not
>>>> determine if there was a working group consensus for change, or what
>>>> it would become if I was to change it.
>>>>
>>>> Yours,
>>>> Joel M. Halpern
>>>
>
>