I agree that the difference between a name and a keyword, is that
the name is not localized by the client, while a keyword should be.
If the client doesn't find the keyword in its table of keywords to
localized names, then the client just displays the keyword as is
(and hopes that the user understands English, which is widely understood).
I also agree that initially, administrators will defines new values
as names, not keywords, since there currently isn't a way for clients
to discover new localized names for keywords that the client was not
built with. On the other hand, we need to specify a way in the future
for a client to discover localized names for keywords in the server that
that client doesn't have a localized name for. =20
When such a discovery mechanism is provided, then an IPP object could even
support an ambituous multi-lingual administrator to be able to define
new keyword values and several localized names in different languages
that the client could query.
So having attributes specified as 'type4 keyword | name' allows for
this future possibility.
But it would help to clarify that until an IPP object supports querying
the name of a keyword in a specified human language, the implementors
SHOULD support allowing administrators to add new attribute values
by defining additional names, not keywords, to the IPP object.
Tom
At 16:34 03/06/1998 PST, Robert Herriot wrote:
>I agree with you that there is some confusion here, particularly where the=
=20
>document says "An administrator MAY define additional values using the=20
>'name' or 'keyword' attribute syntax, depending on implementation." [ line=
=20
>2248, section 4.2.3].
>
>Our intent was to allow an administrator to add new values locally. I have=
=20
>always assumed that a GUI would convert the standard keywords into some=20
>localized word or phrase, but that a GUI would display values created by an=
=20
>administrator as is (to keep things simple). Attributes that allow new=20
>administator values need to distinguish between those values that should be=
=20
>converted and those that should not.
>
>But the statement in the model document leaves me confused because it says=
=20
>that an administrator can call a new value a keyword or a name, and that=20
>some implementation may not support both ways. This makes me think that=
one=20
>of these choices needs to be removed from the standard. The solution=
should=20
>be one of the two below.
>
> o We eliminate the concept of type 4 keywords, and let "name" be the way=
=20
> administrators make extensions. We should encourage GUIs to localize=
=20
> keywords and display names as is. All attributes whose values are type=
4=20
> keywords currently have "name" as an alternate type. So we change
>their
>
> type to "type 3 keyword | name"
>
> o We eliminate "name" from the attributes that are "type 4 keyword |=20
> name" and let a language be associated with keywords. We encourage=
GUIs
>to=20
> leave keywords as is if they aren't in the localization table.
>=20
>I like the first option best. It still leaves two data types for some=20
>attributes, but it is better than allowing a language with keywords when=20
>most have no language associated with them.
>
>
>Bob Herriot
>
>At 01:46 PM 3/5/98 , Carl Kugler wrote:
>>Tom-
>>
>>> Why are there attributes that have both 'type4 keyword' and 'name'
>>> (and hence 'nameWithLanguage) data types?
>>
>>I think that this is a new, different question, and a good one.=A0 Aren't
these
>>the only attributes for which a multi-valued attribute instance may have a
>>mixture of its defined attribute syntaxes?
>>
>>If true, collapsing the redundant '(type4 keyword | name)' to 'name',=
would
>>allow one attribute syntax tag to apply to a whole attribute, even a
>>multi-valued one. It would also make life easier for implementers trying=
to
>use
>>strong typing.
>>
>>=A0 -Carl
>>
>>
>>
>>hastings@cp10.es.xerox.com on 02/09/98 04:46:51 PM
>>Please respond to hastings@cp10.es.xerox.com @ internet
>>To: ipp@pwg.org @ internet, Carl Kugler/Boulder/IBM@ibmus
>>cc:
>>Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo
>>
>>
>>At 14:06 02/02/1998 PST, Carl Kugler wrote:
>>>Attributes with type 4 keywords also allow the 'name' attribute syntax=
for
>>>administrator defined names.=A0 Keywords SHALL be in U.S. English, but
>>attributes
>>>that are indicated to have the 'name' attribute syntax also automatically
>>have
>>>the 'nameWithLanguage' attribute syntax.
>>>
>>>So in general, attributes with type 4 keywords can use the Language
Override
>>>Mechanism?
>>
>>Correct, but because the 13 attributes that have 'type 4 keyword' data=
type,
>>also have the 'name' data type:
>>
>>=A0 +-------------------+----------------------+----------------------+
>>=A0 | job-hold-until=A0=A0=A0 | job-hold-until-=A0=A0=A0=A0=A0=
|job-hold-until-=A0=A0=A0=A0=A0=A0 |
>>=A0 | (type4 keyword |=A0 |=A0 default=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
| supported=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
>>=A0 |=A0=A0=A0 name)=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 (type4 keyword |=A0=
=A0=A0 |(1setOf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
>>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=
name)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | type4 keyword | name)|
>>=A0 +-------------------+----------------------+----------------------+
>>=A0 | job-sheets=A0=A0=A0=A0=A0=A0=A0 | job-sheets-default=A0=A0=
|job-sheets-supported=A0 |
>>=A0 | (type4 keyword |=A0 | (type4 keyword |=A0=A0=A0=A0=
|(1setOf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
>>=A0 |=A0=A0=A0 name)=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=
name)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | type4 keyword | name)|
>>=A0 +-------------------+----------------------+----------------------+
>>
>>=A0 +-------------------+----------------------+----------------------+
>>=A0 | media=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | media-default=A0=A0=A0=
=A0=A0=A0=A0 | media-supported=A0=A0=A0=A0=A0 |
>>=A0 | (type4 keyword |=A0 | (type4 keyword |=A0=A0=A0=A0=
|(1setOf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
>>=A0 |=A0=A0=A0 name)=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=
name)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | type4 keyword | name)|
>>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
>>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=
media-ready=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
>>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
|(1setOf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
>>=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | type4=
keyword | name)|
>>=A0 +-------------------+----------------------+----------------------+
>>
>>not just because they have the 'type 4 keyword' data type.=A0 But we
>>thought that if an administrator is making up names (which is what
>>type 4 keywords are), that an implementation may want to be simple
>>and treat them as names in the language that the administrator is
>>using or may want to be more complex and allow the administrator to
>>define keywords that clients can localize into various languages.
>>
>>Sounds like something for the FAQ:
>>
>>Why are there attributes that have both 'type4 keyword' and 'name'
>>(and hence 'nameWithLanguage) data types?
>>
>>Tom
>>
>>>
>>>=A0 -Carl
>>>
>>>
>>=20
>
>
>