Well,
I think we should remove text/nameWithoutLanguage, cause it's a mess
to have one attribute with two types WithoutLanguage/WithLanguage.
/HOLST
"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 06-11-98 03:16:35
To: Carl Kugler <kugler at us.ibm.com>, ipp at pwg.org
cc: (bcc: Henrik Holst/INT)
Subject: RE: RE: IPP> NLO votes [nlo 4 of 4 - Issue 1.48]
Carl,
If our tentative agreement on nlo 4 of 4 to keep both text/nameWithLanguage
and text/nameWithoutLanguage, then we still need the
"attributes-natural-language" in the response to tell what the implicit
natural language is for any text/nameWithoutLanguage, correct?
On the other hand, if we reverse ourselves and do decide to remove
text/nameWithoutLanguage, then I agree with you, we can make the
"attributes-natural-language" in a response, just a MAY. In fact, we could
go even further to make it a SHOULD NOT. But we don't want to rule it out
altogether, since there be implementations that are always returning
text/nameWithLanguage.
Tom
>-----Original Message-----
>From: Carl Kugler [mailto:kugler at us.ibm.com]
>Sent: Wednesday, November 04, 1998 10:02
>To: ipp at pwg.org>Subject: Re: RE: IPP> NLO votes
>>>>> >Carl and others, including Keith Moore, have tried to express
>> >that the NL/NLO
>> >scheme is unduly complex and prone to error. Carl's proposal
>> >represents a
>> >simpler scheme where every text and name attribute would have
>> >an explicit
>> >natural language thereby simplifying the implementation with
>> >fewer attribute
>> >syntax's, and reducing the number of attributes which have
>> >multiple syntax's -
>> >all with NO LOSS of functionality.
>>>> Exactly. NLO 4 of 4 proposes exactly that: Drop
>textWithoutLanguage and
>> nameWithoutLanguage
>> and always use textWithLanguage and nameWIthLanguage in requests and
>> responses. But 4 of 4 (unlike Carl's proposal) does not change the
>> "attributes-natural-language" Operation attribute in
>requests and keeps it
>> in responses as well for compatibility (though its not used).
>>>I disagree strongly with keeping the (unused)
>"attributes-natural-language" Operation attribute in
>responses. If it's not necessary let's apply Occam's Razor
>and get rid of it. Useless appendages just cause confusion
>for implementors. For example, what value should be sent?
>How does the client check the received value?
>>I'd go along with leaving it in as a MAY, purely for
>historical reasons, with a note to the effect that it's there
>only for compatibility and it is to be ignored.
>> -Carl
>>-----
>See the original message at http://www.egroups.com/list/ipp/?start=4717>--
>Free e-mail group hosting at http://www.eGroups.com/>