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

Apologies if you have already seen the email enclosed below. Apparently
my digital signature results in some people not seeing any contents.
It's very odd, because others apparently are.

Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email protected]] On Behalf Of Deleganes, Ellen M
Sent: Monday, November 06, 2006 8:57 AM
To: [email protected]
Subject: Re: terminology wa Re: XML basics Re: LC model draft
draft-ietf-forces-model-07.txt

I agree that the changes are editorial as opposed to technical. This
discussion is mostly about clarifying terminology, not changing the
basic
definition of the items under discussion.

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

>You lost me a little here. Why should the protocol care? It just
carries
>the modelled data.

I think what Tom is trying to distinguish is a ForCES element from the
XML
use of the term "element". It seems that XML has a specific meaning for
the
word "element" that doesn't match the ForCES usage.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email protected]] On Behalf Of Jamal Hadi Salim
Sent: Monday, November 06, 2006 8:30 AM
To: [email protected]
Subject: Re: terminology wa Re: XML basics Re: LC model draft
draft-ietf-forces-model-07.txt

On Sun, 2006-05-11 at 18:39 +0100, tom.petch wrote:
> 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.
> 

I dont see a problem with the above description. S3 does go into pains
of describing the difference between the two already ("I can do IPV4
forwarding" being a capability and "I can handle 100K /32 routes" being
a constraint. 
Referring to the constraint as a capacity maybe misconstrued as to be a
numeric constraint (as in IPV4 forwarding table capacity)

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

You lost me a little here. Why should the protocol care? It just carries
the modelled data. 
There may be a need to perhaps mark a clear distinction between the data
vs Information model mentioned in passing in the intro. The draft tries
to be both.
The leggo that constructs the model aka "element" or "structure" are
more part of a data model approach whereas the capability/constraint
constructs are more of an information model approach, no?

> My 'arrays' are usually 'tables' with rows and columns which works at
least when
> they are 2-D; 

Table is a better name.

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

You are right, there is a C-like assumption in the data modelling. That
approach is suited to an implementer - isnt that what we want?

Joel, re: protocol change - you sound very concerned: 
IMO, we have always had the constraint that the protocol is dependent on
the model. AFAICS, the changes are editorial not technical, no? i.e it
is not a big deal.

cheers,
jamal