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 at 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/