IPP Mail Archive: IPP> Re: MOD OLD NEW Issue: Contradictory NLO req

IPP> Re: MOD OLD NEW Issue: Contradictory NLO req

Hugo Parra (HPARRA@novell.com)
Tue, 13 Oct 1998 09:40:07 -0600

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=20

>>> "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=20
http://www.egroups.com/list/ipp/3644.html=20
The idea is simple. Eliminate the implicit language form of text and name =
attributes. =20

Specifically:
1. Eliminate "attributes-natural-language" operation attribute.
2. Eliminate "attributes-natural-language" job object attribute.
3. Eliminate "textWithoutLanguage" attribute syntax. =20
4. Eliminate "nameWithoutLanguage" attribute syntax.
5. To allow client to specify desired natural language for Printer-generat=
ed 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 xWithoutLa=
nguage 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. =20
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=3D4596=
=20

--
Free e-mail group hosting at http://www.eGroups.com/