Re: [MODEL] Resolutions to nouns describing LFB class definitions?
Avri Doria <[email protected]> Sun, 8 Jul 2007 17:18:39 -0400
| Newsgroups | gmane.ietf.forces |
|---|---|
| Message-ID | <[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 >