> The most recent postings for the proposed chChannelInformation object
> have used the term "entries" to refer to the various defined value components.
>
> I would like to propose that this term be changed to "keywords" to better
> reflect the nature (both syntax and semantics) of these value components.
>
> It just seems like "entries" conjures up the notion of "table-like" elements,
> ie, "rows" having multiple fields, etc.
>
> Comments?
What I was trying to do was this:
attributes The logical pieces of information that need to be
represented in the prtChannelInformation.
entries The prtChannelInformation consists of a sequence of
entries that represent the attribute information. Each
entry is composed of a name and a value (along with some
delimiting characters). The name identifies the
attribute represented by the entry. There will be
multiple entries corresponding to a single attribute if
the attribute has multiple values.
I found it easier to describe the encoding of multi-valued attributes,
handling of duplicate entries, and the like, if there were separate
terms for the attribute and its representation.
I've heard the things I've referred to as "entries" also called
"name/value pairs," "keyword/value pairs," or "tagged values," but
"entry" seemed simpler. My problem with "keyword" is that it makes me
think of just the name portion of the entry.
I see the conflict with "entry" used to refer to table entries, although
lists, like the prtChannelInformation, certainly also have entries.
Would using "element" instead help distinguish the two?
:: David Kellerman Northlake Software 503-228-3383
:: david_kellerman@nls.com Portland, Oregon fax 503-228-5662