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.
-Carl
"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 3.2.6.2
> 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/