While we're on the subject of natural languages, here is a rerun from May.
Bear with me on this one; it's hard to digest. I found it hard to follow
myself, after four months!
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 has 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 different from
the Job's. Of course, there may be multiple Job object attribute groups 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 into 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 misleading, 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 this NLO
anyway? It has no use on the server side. The only use I can think of at all
is in choosing an orientation for rendering text for individual attributes on a
GUI. I'd be impressed to see a GUI that can render a group of attributes with
some sideways and some up-and-down, and still make sense!
-Carl