Subject: notes on conneg-feature-hash-02

From: Maurizio Codogno <[email-masked]>
Date: Wed, 14 Jul 1999 19:30:15 +0200 (MET DST)

Hi all.
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.

as for the vexata quaestio about direct URL appearance, I still think
that it could be left. It's true that we have the risk that the 
feature set is changed without notice, but in practice what would 
happen if you find that the URI does not have the correct hash?
I'd just write that systems MUST support the hashed form and MAY support
the bare one. 

ciao, .mau.

---

From: Graham Klyne <[email-masked]>
Date: Tue, 20 Jul 1999 10:54:11 +0100

>provided, but I am not sure about it and I think that some word could

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 (since it applies to both hash and URI
forms):

  NOTE:  where a feature set reference is used, 
  its meaning is defined by substitution of the 
  referenced feature expression into the 
  referencing expression.  When all references 
  have been thus replaced, the result is 
  interpreted as a normal feature expression.

  In particular, if a referenced feature 
  expression contains some feature tag that is 
  also constrained by the referencing expression, 
  the constraints are interpreted per [1], 
  without regard for their origin.  e.g. (using 
  some notation introduced below):
    (& (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) )

Does this help to make the intent clearer?

#g

------------
Graham Klyne
([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Tue, 20 Jul 1999 19:41:29 +0100

At 18:40 20/07/99 +0200, Maurizio Codogno wrote:

>"     (& (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.

I regard this as a topic for further study.  Given the other issues at work
here the resolution is far from obvious (to me, at least):  I tried one in
<draft-ietf-conneg-W3C-ccpp-01.txt>, but I don't like that any more.  I now
tend to think some kind of meta-structure may be the way forward, but I
haven't thought it through.

The basic CONNEG syntax as currently defined was deemed to satisfy the
goals set out for the CONNEG.  Further, it has a rigorous structure that I
believe will provide a much more solid foundation for future extension than
might be provided by ad-hoc extensions introduced without a clear view of
the requirement to be satisfied.

>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'd say the spec is quite clear (if not obvious ;-) on this:  the result is
an empty feature set.  That expression is logically equivalent to FALSE, so
there is NO feature collection that it can select.  I'll look to see if I
can slip in a note that  clarifies this without introducing more confusion.

>I don't care, since there is an implicit ordering and I can collapse those
>features to
>
>(& (colors=full) )

Well, no:  see above.

>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 :-)

That makes me an iconoclast too!  No document or receiver can satisfy this
capability expression.

#g

---

From: Graham Klyne <[email-masked]>
Date: Tue, 20 Jul 1999 19:41:33 +0100

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-masked] [mailto:[email-masked]]On
>> Behalf Of Maurizio Codogno
>> Sent: Tuesday, July 20, 1999 9:41 AM
>> To: [email-masked]
>> Subject: Re: notes on conneg-feature-hash-02
>> 
>> 
>> 
>> " From: Graham Klyne <[email-masked]>
>> 
>> " >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 [...]
>> 
>> I hope that what I wrote makes some sense...
>> 
>> ciao, .mau.
>> 
>> 
>
------------
Graham Klyne
([email-masked])

---

From: Maurizio Codogno <[email-masked]>
Date: Thu, 22 Jul 1999 10:23:04 +0200 (MET DST)

" >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'd say the spec is quite clear (if not obvious ;-) on this:  the result is
" an empty feature set.  That expression is logically equivalent to FALSE, so
" there is NO feature collection that it can select.  I'll look to see if I
" can slip in a note that  clarifies this without introducing more confusion.
" 
" 
" >I don't care, since there is an implicit ordering and I can collapse those
" >features to
" >
" >(& (colors=full) )
" 
" Well, no:  see above.

Ok. Thus, the only ordering possible with features is the numeric one
for those features which have numerical values: for every other
feature, the only comparison you can have is "is/is not equal".

I guess this has to be written explicitly in the draft, to avoid
false interpretations like mine.

ciao, .mau.