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.