Re: [MODEL] Resolutions to nouns describing LFB class definitions?

How about "ForcesElement" for the cases in the definitions where
there is a fit for the element being a component of a structure or
property? One could probably do a s/element/ForcesElement/g and get away
with it. 

The other more bothersome one is "attributes" which is clearly a
"property" of an "element" (pun intended). i.e we have both
"property" (lucky for us, thats not taken by XML), and "attribute" all
over the map - sometimes morphed to the same semantic.

For that:
LFBAttributes would fit nicely for the case of attributes as defined in
the LFBClassDefs. For consistency, why dont we prefix everything under
LFBClassDefs with "LFB" (eg LFBCapabilities, etc).

This still leaves us with the dilema of properties (of ForcesElement) as
defined in XMLish speak such as 
<array type="variable-size" max-length="8"> vs the forces model speak of
arrayElementProperties  (which has attributes/properties like
highestUsedSubscript).

It will be _tricky_, but nonetheless tempting, to say leave those in XML 
speak but still allow for the protocol operations to target them to 
simplify life. The other alternative is to get rid of XML variant maybe?
Or maybe we need both?

cheers,
jamal

On Mon, 2007-08-01 at 16:09 -0500, Joel M. Halpern wrote:
> Let me just restate the problem.
> There are a number of model components which all behave in similar 
> fashions, and frequently need to be referred to in some easily 
> understood fashion.  These include the components of structures and 
> properties.  They include the attributes and capabilities of the LFB 
> class.  They include items in arrays in one of the above.
> 
> So I had used "element" for that.  Tom rightly raised the concern 
> that this (and attribute) have very clear XML meanings, and we can 
> end up sometimes talking about XML elements and sometimes tlaking 
> about ForCES elements.  Even if we are careful, this seems likely to 
> lead to confusion.
> So we need some term for the ForCES element.  (Since we are not going 
> to change the XML terminology :-)
> 
> But no one has come up with proposed terminology.  If no one comes up 
> with anything else, I will try using component, and see how that 
> works.  (I doubt that is a good choice.)
>