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

<inline>
Tom Petch
----- Original Message -----
From: "Deleganes, Ellen M" <[email protected]>
To: <[email protected]>
Sent: Monday, November 06, 2006 8:14 PM
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.

<tp> yes very much so</tp>

>
> >> '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.
>
<tp> Again, very much so.  To take a line from -model,

 <attribute access="read-write" elementID="1">

attribute is an XML element while elementID is an XML attribute; that is what I
would most like to amend, get away from attribute as used by ForCES and, if
possible, element as well.  As I said, I like 'capability' ditto 'configuration'
'customisation' 'potentiality' 'property' ....

And as Joel said, it would be helpful to have an umbrella term for what is
currently either (the XML element) <capability> or <attribute> in ForCES.

In general, most of what can be done in XML can be done by using XML attributes
of XML elements or by using XML elements per se. So a second point is, I am
unclear in -model whether the intention is that all pieces of data that a CE can
read or write are expressed as XML elements or are some of them XML attributes
(of XML elements).  This has ramifications for identifiers and namespaces
and -protocol.

</tp>
>
> 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.
> >=20
>
> 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.=20
> 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.=20
> 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;=20
>
> 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).
> >=20
>
> 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:=20
> 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