Re: notes on conneg-feature-hash-02

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