Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt

I do like the terms in s3.1 of -model; they - capability and
constraint(capacity) - seem the most natural to me.  I have used the term
'function' in my e-mails because that is not in the I-Ds and so seemed neutral
in any discussion, and because it is for me what it is we are talking about, as
much as capability.  The two could be combined; functional capability and
functional constraints.

'element' in -protocol could be 'protocol element' which, for me at least, is
markedly different to (data) element in XML

My 'arrays' are usually 'tables' with rows and columns which works at least when
they are 2-D; and I allow for atomic elements or structures in the rows.  (I
sense a C language background to the terminogy of ForCES whereas I am more
mathematics, ASN.1 and SNMP).

But as you say, hearing more voices would be most welcome.

Tom Petch

----- Original Message -----
From: "Deleganes, Ellen M" <[email protected]>
To: <[email protected]>
Sent: Friday, November 03, 2006 6:00 PM
Subject: Re: terminology wa Re: XML basics Re: LC model draft
draft-ietf-forces-model-07.txt


It looks like there is general agreement that the terminology ought to
be fixed because the current terminology is causing confusion (though it
would be good for more people to weigh in).

I like the idea of replacing "attribute" with "capability". We more or
less equate these in the model document anyway. Section 3 states "FE
attributes provide information at the FE level, particularly the
capabilities of the FE at a coarse level". In this case, capabilities
describe the functions the FE can perform and capacity constraints.

Renaming "element" is going to be more awkward because it doesn't look
like a simple case of replacing text. This is more an argument for
fixing this because it indicates the term is overloaded and confusing.
In one case element is used to describe a protocol element, in other
cases it is describing a data structure that is part of some other
structure (such as the array) or is an atomic data type contained within
a structure. I'm not sure how to disambiguate this, but I can see how
this can cause some level of confusion - not to mention the term element
has some connotation in XML. Unfortunately, I don't have a good
suggestion on how to fix this, prepending a prefix seems like the
easiest.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email protected]] On Behalf Of Joel M. Halpern
Sent: Tuesday, October 31, 2006 2:33 PM
To: [email protected]
Subject: Re: terminology wa Re: XML basics Re: LC model draft
draft-ietf-forces-model-07.txt

What Joel thinks about the naming of the components of the LFB
Classes and structures is:
It is going to be awkward to fix
But keeping it as is would produce far more confusion for far more
people over the long term.

So we seem to need to change the terms (element and attribute
referring components of the structures / LFB Classes.)
Note that such a change will likely also affect the protocol
document, since it talks about these things as well.

After that, I am willing to change them to almost anything.  (But I
doubt it would help to declare that LFB Classes and structs have
Foos, and some Foos are also Bars.  So better words are sought. I
believe I have one suggestion on file, but would love to see actual
discussion and input from other participants.)

Yours,
Joel

At 03:24 PM 10/31/2006, Jamal Hadi Salim wrote:
>What does Joel think about this?