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
- Model draft Joel M. Halpern
- Re: Model draft tom.petch
- Re: Model draft tom.petch
- Model draft Joel M. Halpern
- Re: Model draft Joel M. Halpern