Paul-
The reason I brought all this up in the first place is that I believe the June spec is broken in regards to Natural Language. It is self-contradictory, or at least open to multiple valid interpretations (==> interop problems). See
http://www.egroups.com/list/ipp/3641.html
If it ain't broke, don't fix it. But what if it is broke? Maybe part of the reason the document authors got it wrong is that it is too complex. If we need to make changes anyway, maybe we can simplify things on the way.
-Carl
"K.I.S.S."
> -----Original Message-----
> From: Harry Lewis [mailto:harryl@us.ibm.com]
> Sent: Friday, November 06, 1998 9:40 AM
> To: ipp@pwg.org
> Cc: stuart.rowley@kyocera.com
> Subject: Re: IPP> MOD - Tentative decision on natural language overri
>
>
> Stuart, you echo my sentiments exactly. I have tried, on the wire and in the
> calls to bring the focus back to Carl's original (and much simpler)
> observations. (See http://www.pwg.org/hypermail/ipp/1490.html). I think the
> problem is that some implementations are already using some of the
> (difficult
> to understand) "features" in striving for conformance to the June 30
> drafts.
> It's just unfortunate that we were not able to focus sooner on the problem
> which was surfaced in May. I believe Tom tried to bend Carl's proposal into
> the
> reality of the situation... looking for a compromise solution. I agree... it
> looks that much more complicated in this context.
>
> It is fairly well agreed there is not much we can do with respect to Servers
> (Printers?), at this point but some hope may still lay in the Clients. If we
> can restrict client behavior (say, to always use textWithLanguage) it might
> govern server response (to, similarly, always use textWithLanguage)...
> nearly
> achieving Carl's proposal. But, some Servers already have decided to make
> use
> of textWithoutLanguage in situations where Languages on the request and
> response are identical (a common sense implementation given the absence of a
> rule like Carl was proposing... "always use textWithLanguage").
>
> So, we feel pretty boxed in. I agree, however, any reasoning discussed on
> the
> call should be echoed on the DL for all to understand.
>
> Harry Lewis - IBM Printing Systems
> harryl@us.ibm.com
>
>
>
> owner-ipp@pwg.org on 11/05/98 10:07:44 PM
> Please respond to owner-ipp@pwg.org
> To: hastings@cp10.es.xerox.com, ipp@pwg.org
> cc:
> Subject: Re: IPP> MOD - Tentative decision on natural language overri
>
>
> 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@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@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=4807
-- Free e-mail group hosting at http://www.eGroups.com/