IPP> MOD - Tentative decision on natural lang

IPP> MOD - Tentative decision on natural lang

IPP> MOD - Tentative decision on natural lang

Carl Kugler kugler at us.ibm.com
Mon Nov 9 15:25:07 EST 1998

NLO 3of4 + NLO 4of4 is essentially the same as my original proposal except that instead of adding a new, OPTIONAL "natural-language-requested" operation attribute, the original, REQUIRED, "attributes-natural-language" operation attribute is retained.  I agreed to this compromise after it was explained to me that a MANDATORY override of the Printer's "natural-language-configured" might be useful to multi-lingual operators, separator-sheet generators, and email notifiers (although one wonders why we need "natural-language-configured", then).  Also, it is more compatible with existing implementations.  But it does use more bandwidth.

In my opinion, NLO 4of4 should be modified so that the "attributes-natural-language" operation attribute is OPTIONAL in responses.

The NLO 2of3 + NLO 3of3 compromise proposal retains almost none of the benefits I listed in my original proposal under "Advantages".  It does cause less breakage to some existing implementations.  However, the changes required by NLO 3of4 + NLO 4of4 are all deletions;  nothing new is added.


"There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." --C.A.R. Hoare 

> Apparently the participants in the telecon and those "voting" on the 
> mailing list are completely different groups of individuals! Except for Bob 
> Herriott, no one expressed any con arguments for NLO 4 of 4. I only saw yes 
> "votes" (about 10 or 15 of them). So why the telcon decision of No. There 
> is not even any reasons given why this decision was reached. Where is the 
> discussion on the mailing list?
> This type of mass back on forth makes me wonder how many really have a 
> clear understanding of these NLO issues (not that I do). Nearly everyone 
> has expressed that the current mechanisms are overkill and very hard to 
> understand.
> I think the only really clearly articulated discussion of this on the 
> mailing list has been Carl Kugler's emails. On Oct 9 Carl sent the 
> following email titled IPP> Re: MOD OLD NEW Issue: Contradictory NLO req. 
> This email suggests a very clear and to me appropriate solution. I never 
> saw on the list anyone state why not to accept Carl's proposal. After this 
> email, we received the issue broken into several inter-related issues by 
> Tom (which I read over and over and over, trying to understand). 
> I would now challenge those in the telecon who decided to keep name/text 
> withoutLanguage to re-read Carl's email (below) and state in what ways his 
> proposal is flawed. Until someone can adequately shoot down this clear 
> proposal of Carl's, then his proposal is what I am in favor of.
> Thanks,
> Stuart
> ------------------------------------------------------------------------ 
> Stuart Rowley                       Kyocera Technology Development, Inc. 
> Network Product Dev. Mgr.           3675 Mt. Diablo Blvd. #330 
> Printer Division                    Lafayette, CA 94549 
> stuart.rowley at kyocera.com           925 299-7206    Fax: 925 299-2489 
> ------------------------------------------------------------------------
> From Carl Kugler, 10/9/98
> IPP> Re: MOD OLD NEW Issue: Contradictory NLO req
> -------------------------------------
> Here is a proposal for simplifying IPP's natural language model.  It's 
> basically an elaboration of a suggestion made by Keith Moore in 
> http://www.egroups.com/list/ipp/3644.html
> The idea is simple.  Eliminate the implicit language form of text and name 
> attributes.  
> Specifically:
> 1.  Eliminate "attributes-natural-language" operation attribute. 
> 2.  Eliminate "attributes-natural-language" job object attribute. 
> 3.  Eliminate "textWithoutLanguage" attribute syntax.  
> 4.  Eliminate "nameWithoutLanguage" attribute syntax.
> 5.  To allow client to specify desired natural language for 
> Printer-generated text from multi-lingual Printers, add a new, OPTIONAL, 
> "natural-language-requested" attribute to override Printer's 
> "natural-language-configured".
> Now every text and name attribute has an explicitly specified natural 
> language.
> Advantages:
> 1.  Constructing responses is simpler.  No need to consider a hierarchy of 
> implicit language contexts.  Printer never needs to convert from 
> xWithoutLanguage to xWithLanguage.
> 2.  Interpreting messages is simpler.  Currently the same message can take 
> many forms, depending on use of redundant NLOs, etc.
> 2.  Comparing name and text values is simpler.  No need to search a 
> three-level precedence hierarchy to find the language of a value being 
> compared.  Name and text values can be compared out of context.
> 3.  Implementation is simpler.  Fewer attribute syntaxes required.  12 
> fewer attributes have multiple syntaxes.  One less attribute in a special, 
> reserved, required position.
> 4.  Bandwidth savings.  Using the examples from Section 9 of PRO:
> 9.1: save 30 bytes
> 9.2: save 23 bytes
> 9.3: save 30 bytes
> 9.4: save 30 bytes
> 9.5: save 37 bytes
> 9.6: save 37 bytes
> 9.7: save 60 bytes.
> 5.  No loss in functionality over the original model.    
> 6.  Easier to specify and understand.
> Disadvantage:
> 1.  Reduced job security for IPP consultants ;-)
> -Carl
> ------------------------------------------
> ______________________________ Reply Separator 
> _________________________________ Subject: IPP> MOD - Tentative decision on 
> natural language override (
> Author:  "Hastings; Tom N" <hastings at cp10.es.xerox.com> at ~internet Date:   
>  11/5/98 7:15 PM
> At our IPP telecon, Wednesday, 11/04/1998, we tentatively agreed to the 
> following decisions.  Please response to these tentative decisions on the 
> mailing list so that we may make final decisions at the upcoming IPP WG 
> meeting next week.
> Decision 1: 
> Yes for nlo 3 of 4. (Issue 1.47) 
> A name/textWithoutLanguage does not get its implicit 
> language from the attributes-natural-language attribute in the job attribute
> group in a Get-Jobs response. It always gets the language for each job in 
> the response from the attributes-natural-language operation attribute.  This 
> is a change from the June draft by deleting a paragraph in section 
> Get-Jobs response (that required the job-level natural language override to 
> be returned for each job whose natural language differed from that of the 
> response as a whole).
> Decision 2:
> No for nlo 4 of 4.  (Issue 1.48)
> Keep both text/nameWithLanguage and 
> text/nameWithoutLanguage attribute syntaxes for 'text'/'name' attributes as 
> in the June draft. Thus, when a text/name attribute value's natural language 
> is the same as the attributes-natural-language operation attribute, the 
> value in the protocol can either contain text/nameWithLanguage or 
> text/nameWithoutLanguage.
> We also discussed nlo 2 of 4.  (Issue 1.46)
> To clarify that a request or response MAY contain a redundant use of 
> text/nameWithLanguage, i.e., the explicit natural language of an attribute 
> value is the same as the natural language specified for the request or 
> response as a whole in the attributes-natural-language operation attribute. 
> We agreed that to make it simply a MAY (implementer option), since some 
> implementers want to remove redundancy in their requests and response, while 
> other implementers want to always pass name and text with explicit natural 
> languages.  Thus we could not agree to make redundant NLO at the attribute 
> level a SHOULD or a SHOULD NOT, but merely a MAY.
> Tom Hastings
> (310) 333-6413

See the original message at http://www.egroups.com/list/ipp/?start=4802
Free e-mail group hosting at http://www.eGroups.com/

More information about the Ipp mailing list