I am hesitant to cut things out of the specs at this stage. What is the
reaction among people who have already launched or are close to launch
products?
Carl-Uno
> -----Original Message-----
> From: Hugo Parra [mailto:HPARRA@novell.com]
> Sent: Tuesday, October 13, 1998 8:40 AM
> To: ipp@pwg.org
> Subject: IPP> Re: MOD OLD NEW Issue: Contradictory NLO req
>
>
> I'm with Carl on this one. The current mechanism for
> specifying and deriving the natural language of a given
> attribute is error prone (and in my opinion, an overkill -
> we've supported multi-language print environments for some
> time now without the capability for overriding language ant
> the granularity described in IPP and haven't once received a
> hard requirement from our customers to do so.) Whatever we
> can do to make it simpler, I'm in favor of.
>
> -Hugo
>
> >>> "Carl Kugler" <kugler@us.ibm.com> 10/09 1:54 PM >>>
> 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
>
> -----
> See the original message at
http://www.egroups.com/list/ipp/?start=4596
-- Free e-mail group hosting at http://www.eGroups.com/