RE: notes on conneg-feature-hash-02

Larry,

I think we take different views on this.

The combination rules for Boolean expressions are (a subset of) those that
are applicable to standard predicate calculus.  They do not vary with the
context in which they are used.  Hence, the expression (& (colors=limited)
(colors=full)) is logically FALSE.  Recognizing 'limited' as a subset of
'full' and interpreting the expression accordingly is outside the scope of
the current capability expression specification.

The examples I gave were combining constraints based on '<=' and '=', and
would be equally applicable in any context.  (The exact form of expression
that one would chose for different contexts might vary:  I would suggest
using 'pix-x=n' for a document, and 'pix-x<=m' for a receiver.)

#g
--


At 10:13 20/07/99 PDT, Larry Masinter wrote:
>I'm not sure, but it seems that the combination rules
>for boolean expressions differ depending on whether the
>features are being used to describe recipient capabilities,
>document profiles, or sender output ranges.
>
>(& (colors=limited) (colors=full)) resolves to
>(colors=limited) if you're describing recipient
>capabilities, and resolves to (colors=full) if
>you're describing sender output range or
>a document profile.
>
>That we're using the same syntax for each purpose doesn't
>mean that they imply the same ordering relationships or
>combination rules.
>
>I think that the examples that Maurizio gave were
>"document profiles" but that Graham was giving
>"recipient capability" examples in the document.
>
>Larry
>-- 
>http://www.parc.xerox.com/masinter
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]]On
>> Behalf Of Maurizio Codogno
>> Sent: Tuesday, July 20, 1999 9:41 AM
>> To: [email protected]
>> Subject: Re: notes on conneg-feature-hash-02
>> 
>> 
>> 
>> " From: Graham Klyne <[email protected]>
>> 
>> " >I have also read conneg-feature-hash-02...
>> " >
>> " >sect. 3.2 : I am not sure what happens if we have an URI (either 
>> " >direct or dereferenced through a hash) and some explicit feature.
>> " >My personal logic will say that the latter overrides the "defaults"
>> " >provided, but I am not sure about it and I think that some word could
>> " >clarify the issue.
>> " 
>> " Thank you for raising this issue.  In fact, there is no concept of
>> " "default" and "override" in the current notation.  I propose to add
>> " something along the following lines at the end of the introductory
text in
>> " section 3, just before section 3.1 [...]
>> 
>> "     (& (pix-x=100) (pix-y<=300) (h.1234567890) )
>> "   where (h.1234567890) resolves to:
>> "     (& (pix-x<=200) (pix-y<=150) )
>> "   yields a result equivalent to:
>> "     (& (pix-x=100) (pix-y<=150) )
>> 
>> Ok. This is clear: there is no equivalent of a "style sheet" which
>> can be overridden in particular cases. I won't argue with this: probably
>> this is the best way to deal with features in practice.
>> 
>> But then I think the draft should mandate (even if just in a NOTE) 
>> what happens when there are contrasting informations. If I receive
>> something on the lines of 
>> 
>> (& (colors=limited) (colors=full) )
>> 
>> I don't care, since there is an implicit ordering and I can collapse those
>> features to
>> 
>> (& (colors=full) )
>> 
>> But if I receive
>> 
>> (& (pix-x=100) (pix-y<=300) (pix-x=200) (pix-y<=150) )
>> 
>> (in whichever way this will be assembled) I do not know what to do,
>> since pix-x cannot be both 100 and 200. My inclination is to reject
>> the document altogether, but I am an iconoclast :-)
>> 
>> I hope that what I wrote makes some sense...
>> 
>> ciao, .mau.
>> 
>> 
>
------------
Graham Klyne
([email protected])