terminology was Re: Model draft

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

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