Re: Hyperlinks and content negotiation

Smylers wrote:
> Mike Kelly writes:
>
> Content negotiation could succeed if only those who know what they are
> doing touch it, that typical authors aren't somehow tempted to start
> playing with it.  That's possible, but not certain.  I don't know how
> we'd gather data either way.
>   

Content negotiation exists as a standardized feature in the HTTP spec. 
If there are aspects of HTTP that you think are unnecessary or wrong, 
and need addressing - this should be taken up with the relevant bodies 
controlling the HTTP spec - any other approach to 'solving' these 
/perceived/ problems , regardless of intention, is bad (and potentially 
damaging) governance practice.

Meanwhile; I think it would be most productive for HTML to recognize its 
important role in driving HTTP applications, and look to provide (where 
possible) standardized mechanisms by which developers can leverage all 
relevant features of HTTP.

I think conneg is a relevant, valuable feature of HTTP that HTML5 is 
capable of provisioning for, at relatively little risk/cost.

>   
>>>> There are use cases in which the distinction between a resource's
>>>> representations are relevant to the flow of an html driven
>>>> application, e.g. the difference to a browser between an atom and
>>>> an html representation of a blog resource.
>>>>         
>> It is not that using separate URIs "doesn't work", just that it may be
>> a sub-optimal for a particular system that would benefit more from a
>> strictly standardized distinction between resources and
>> representations.  A clear distinction between the two allows
>> intermediaries to make valuable, automated assumptions about the
>> significance of a request.
>>     
>
> Please could you be more specific about these assumptions and their
> value.  HTML5 is designed by finding problems that need to be solved
> first, and then looking for solutions to those problems.
>
> (In this case it sounds like content negotiation may be the only
> solution to the particular problem, but for the rigor of the spec we
> don't want to add features without being sure what they are for and that
> they are the best way of solving the problem.)
>
>   
>>> In what way does it help for a cache to cache a blog's homepage and
>>> feed labelled with the same URL compared with caching them with
>>> separate URLs?
>>>       
>> The benefits are realized in terms of automated cache invalidation.
>> Modifying a resource should automatically invalidate all of its
>> representations.
>>     
>
> Thanks -- that makes sense.  You mention "assumptions" in plural above,
> so I presume there are others?
>
>   

Plural for caches in the sense that various HTTP request methods could 
cause invalidation (i.e. POST/PUT/DELETE)

And also in the sense that other types of intermediary mechanism could 
leverage a standardized distinction - e.g. proxy routing rules, etc. I 
guess these could be explained in more detail if necessary.. but is 
automated cache invalidation not a valuable enough example on its own?

>> It's not a perfect solution to all problems - it's a trade-off.  If
>> highly-efficient automated caching is more valuable to your system
>> than being able to avoid the highly risky world of plain text URIs and
>> grumpy twitter users, then there is an obvious choice to be made.
>>     
>
> That sounds fair enough.  Do you have any evidence of the numbers of
> developers who would choose the cache-invalidation advantage over the
> plain-text URL advantage?
>   

No - but that is not at all surprising given that it isn't a viable 
option right now!

Is this even necessary if we are in agreement that the caching use case 
makes sense, and has significant value?

> Unfortunately HTML5 can't cater for every valid requirement, so
> generally doesn't add features that would be useful to only a very small
> number of authors (for example HTML5 doesn't add a <ship> element,
> despite some authors having a very valid requirement to distinguish
> names of ships on their pages; mentioning ships simply isn't common
> enough).
>   

I understand the point you are making but don't feel that is a sensible 
or helpful comparison for this case.

Cheers,
Mike

Received on Saturday, 17 October 2009 13:13:35 UTC