Subject: Re: IPP> MOD Need Clarification re: Type4 keywords [input fo

From: Carl Kugler <[email-masked]>
Date: Thu, 5 Mar 1998 16:46:00 -0500

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.  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.

  -Carl

[email-masked] on 02/09/98 04:46:51 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ 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.  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:

  +-------------------+----------------------+----------------------+
  | job-hold-until    | job-hold-until-      |job-hold-until-       |
  | (type4 keyword |  |  default             | supported            |
  |    name)          |  (type4 keyword |    |(1setOf               |
  |                   |    name)             | type4 keyword | name)|
  +-------------------+----------------------+----------------------+
  | job-sheets        | job-sheets-default   |job-sheets-supported  |
  | (type4 keyword |  | (type4 keyword |     |(1setOf               |
  |    name)          |    name)             | type4 keyword | name)|
  +-------------------+----------------------+----------------------+

  +-------------------+----------------------+----------------------+
  | media             | media-default        | media-supported      |
  | (type4 keyword |  | (type4 keyword |     |(1setOf               |
  |    name)          |    name)             | type4 keyword | name)|
  |                   |                      |                      |
  |                   |                      | media-ready          |
  |                   |                      |(1setOf               |
  |                   |                      | type4 keyword | name)|
  +-------------------+----------------------+----------------------+

not just because they have the 'type 4 keyword' data type.  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

>  -Carl

---

From: Robert Herriot <[email-masked]>
Date: Fri, 06 Mar 1998 16:34:19 -0800

I agree with you that there is some confusion here, particularly where the 
document says "An administrator MAY define additional values using the 
'name' or 'keyword' attribute syntax, depending on implementation." [ line 
2248, section 4.2.3].

Our intent was to allow an administrator to add new values locally. I have 
always assumed that a GUI would convert the standard keywords into some 
localized word or phrase, but that a GUI would display values created by an 
administrator as is (to keep things simple).   Attributes that allow new 
administator values need to distinguish between those values that should be 
converted and those that should not.

But the statement in the model document leaves me confused because it says 
that an administrator can call a new value a keyword or a name, and that 
some implementation may not support both ways.  This makes me think that one 
of these choices needs to be removed from the standard.  The solution should 
be one of the two below.

   o We eliminate the concept of type 4 keywords, and let "name" be the way 
      administrators make extensions.  We should encourage GUIs to localize 
    keywords and display names as is. All attributes whose values are type 4 
       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 | 
      name" and let a language be associated with keywords. We encourage GUIs
to 
      leave keywords as is if they aren't in the localization table.
 
I like the first option best.  It still leaves two data types for some 
attributes, but it is better than allowing a language with keywords when 
most have no language associated with them.

Bob Herriot

---

From: Tom Hastings <[email-masked]>
Date: Tue, 17 Mar 1998 17:58:27 PST

I disagree that we should get rid of one of the implementor choices for
the 'type4 keyword | name' syntaxes of several attributes that
administrators are likely to define additional values, such as "media",
"job-hold-until", 
and "job-sheets", so maybe we need to clarify the Model document.

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.  

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