Original message: http://www.egroups.com/list/ipp/3641.html
Re: IPP> MOD> Another IPP 1.0 issue
By Carl Kugler @us.ibm.com
Friday May 29, 1998 11:42 AM PST
I think this text from MOD section 3.1.4.1 is misleading:
>The IPP object SHALL remember that natural language for all
>client supplied attributes, and when returning those attributes
>in response to a query, the IPP object SHALL indicate that
>natural language.
>
>"For example, the "job-name" attribute MAY be supplied by the
>client in a create request. The text value for this attribute
>will be in the natural language identified by the
>"attribute-natural-language" attribute, or if different, as
>identified by the Natural Language Override mechanism.
>If supplied, the IPP object will use the value of the "job-name"
>attribute to populate the Job object's "job-name" attribute.
>Whenever any client queries the Job object's "job-name"
>attribute, the IPP object returns the attribute as stored and
>uses the Natural Language Override mechanism to specify the
>natural language, if it is different from that reported in
>the"attributes-natural-language" operation attribute of the
>response.
It subtly conflicts with this text from MOD section 3.2.6.2:
>For any job submitted in a different natural language than the natural=
>language that the Printer object is returning in the
>"attributes-natural-language" operation attribute in the Get-Jobs
>response, the Printer SHALL indicate the submitted natural language by=
>returning the Job object's "attributes-natural-language" as the first
>Job object attribute, which overrides the
>"attributes-natural-language" operation attribute value being returned=
>by the Printer object. If any returned 'text' or 'name' attribute
>includes a Natural Language Override as described in the sections
>4.1.2 and 4.1.4, the Natural Language Override overrides the Job
>object's "attributes-natural-language" value and/or the
>"attributes-natural-language" operation attribute value.
There is a precedence hierarchy here:
1. Natural Language Override
2. Job object's "attributes-natural-language" value
3. "attributes-natural-language" operation attribute of the response.=
1 overrides 2 and 3, 2 overrides 3.
So this statement in 3.1.4.1:
>Whenever any client queries the Job object's "job-name" attribute, the=
>IPP object returns the attribute as stored and uses the Natural
>Language Override mechanism to specify the natural language, if it is
>different from that reported in the "attributes-natural-language"
>operation attribute of the response.
and this one in 3.1.4.2:
>For any 'text' or 'name' attribute or status message in the response
>that is in a different natural language than the value returned in
>the"attributes-natural-language" operation attribute, the IPP object
>SHALL use the Natural Language Override mechanism (see sections 4.1.2
>and 4.1.4) on each attribute value returned.
are incorrect. The IPP object uses the Natural Language Override
mechanism to specify the natural language if it is different from the
Job object's "attributes-natural-language" value (where applicable),
which is the case only when the client used the Natural Language
Override at submission time. Thus, the Printer never needs to use
the Natural Language Override in a response except for those
attributes that the client supplied with Natural Language Override.
[Get it? 3.1.4.1 and 3.1.4.2 say NLO must be used if a Job attribute h=
as a
language different from the response's overall natural language, but 3=
.2.6.2
says NLO must be used only if the Job attribute has a language differen=
t from
the Job's. Of course, there may be multiple Job object attribute group=
s in a
single response. 3.1.4.1 and 3.1.4.2 are not consistent with 3.2.6.2.=
It's
subtle, but you find these things when you set out to put the model int=
o code.
It's gotta be one way or the other.]
Somewhat related question: is it ALLOWABLE for an IPP object to use
the Natural Language Override mechanism in cases where it is NOT
necessary (i.e., would be redundant with a default specified by a Job
object's "attributes-natural-language" value or the
"attributes-natural-language" operation attribute of the response)?
[I think we're now saying yes, which implies that 3.1.4.1, while mislea=
ding, is
technically not incorrect. It just calls for more NLO overrides than
necessary.]
P.S. Does it really need to be this complicated? Of what utility is t=
his NLO
anyway? It has no use on the server side. The only use I can think o=
f at all
is in choosing an orientation for rendering text for individual attribu=
tes on a
GUI. I'd be impressed to see a GUI that can render a group of attribut=
es with
some sideways and some up-and-down, and still make sense!
-Carl
=