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

----- Original Message -----
From: "Wang,Weiming" <[email protected]>
To: <[email protected]>
Sent: Monday, July 09, 2007 3:29 PM
Subject: Re: [MODEL] Resolutions to nouns describing LFB class definitions?


> I also think it's not a good choice changing the 'element' name for ForCES. I
have to say here the usage condition is quite clear by context of XML or ForCES,
and never cause confusion. Our experience also show that this is really not a
question. We never had a problem or confusion on this in our work in fact.
>
> thanks,
> Weiming
>
I do not doubt that you have never had a problem, nor would anyone who has gone
from BOF to WG to framework to protocol to data model.  But who is the RFC
written for?  For such people, or for the engineer with a good familiarity with
the lower layers of the IPS (but not the background in ForCES), with XML in his
toolkit (like ABNF a decade or two ago) and so who has a very clear idea what an
attribute and element is, in the context of a data model written in XML?

For such a person, and for me, the document is unnecessarily tough going which
is why I urged - and urge - change.  As it stands, a ForCES element is identifed
by an ordered set of integers, which are specified by the elementID attribute on
the attribute element.  The time you will find the wisdom, or otherwise, of this
choice, could be at IETF Last Call, when people of the ilk I described above,
may read this and respond.

Alternatively, do we have an XML cadre, like MIB doctors and security
directorate, whose wisdom we could invite before then?

Tom Petch

> ----- Original Message -----
> From: "Avri Doria" <[email protected]>
> > hi,
> >
> > i'd opt for not changing terminology and being careful to use the
> > modifiers XML and ForCES.
> >
> > If we call ForCES elements and attributes something else, we still
> > may cause confusion until people understand the new terms refer to
> > ForCES elements and attributes.
> >
> > a.
> >
> > On 8 jul 2007, at 16.49, Joel M. Halpern wrote:
> >
> >> The text below is from a message I sent to the list 6 months ago.
> >> No one seems to have commented.
> >> That leads to a conclusion and a question.
> >> The conclusion is that I should stick with the proposed replacement
> >> use of "component."
> >> The question is whether I should fix this at all?  On the one hand,
> >> the terminology conflict is really unfortunate.
> >> On the other hand, to change it I will need to change the XML
> >> schema, and that will mean a required change to the protocol draft.
> >>
> >> (Tom Petch noticed the original conflict in usage.  Jamal and I
> >> discussed it on the list, and privately since.  Protocol team, I
> >> would like to hear from you.)
> >>
> >>
> >> 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.)
> >>
> >> Yours,
> >> Joel
> >>