Re: Model draft

"tom.petch" <cfinss@dial.pipex.com> Thu, 27 December 2007 17:15 UTC

Message-Id: <THU.27.DEC.2007.181545.0100.>
Date: Thu, 27 Dec 2007 18:15:45 +0100
From: "tom.petch" <cfinss@dial.pipex.com>
Subject: Re: Model draft
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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" <joel@stevecrocker.com>
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