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