Re: Accept atribute on forms and links

On Thu, Jun 19, 2014 at 5:34 PM, Jose Antonio Illescas del Olmo <
jose.illescas@gmail.com> wrote:

>
>
>
> On Thu, Jun 19, 2014 at 5:59 PM, Cameron Jones <cmhjones@gmail.com> wrote:
>
>> On Thu, Jun 19, 2014 at 3:58 PM, Jose Antonio Illescas del Olmo <
>> jose.illescas@gmail.com> wrote:
>>
>>> Anchors are GETing resources, resources has many representations (html,
>>> pdf, png, txt)
>>>
>>>    I would like to request custom representation (for example pdf) on
>>> link or form without using the ugly extension mechanism (*.pdf)
>>>
>>
>>> And rely on server content negotiation... yes also I like to specify a
>>> list of preferred representations (not only one)
>>>
>>>    image/png, image/jpg, image/gif, image/svg-xml  (this is my list of
>>> preferred representations, or mime-types, and I don't like any other image
>>> format)
>>>
>>>
>>>
>> One problem with this is that the URL will no longer work if it is
>> outside of the original document. For forms this is ok, but people expect
>> links to just work.
>>
>>
> Why?
>

Because you need to override the Accept header in order for the link to
access the resource you have indicated...ie:

<a href="/formula" accept="application/mathml+xml">Cick for the Math
Formula</a>
<a href="/formula" accept="application/pdf">Click for the PDF Formula</a>
<a href="/formula" accept="image/jpg">Click for the JPG Formula</a>

These links are non-transportable outside the context of the document. URIs
are supposed to have "Universality", "Global Scope" and "Sameness":

http://www.w3.org/DesignIssues/Axioms.html



>
> On my application every resource has an PDF representation, if not,
> received a response error
>
>       406 - Not Acceptable (Representation not available)
>
> Or, if server not has, this representation can server default
> representation (*/*)
>


I think you are mixing the definition of what the resource is - is it a
specific format of the content or is it a general information resource
which uses content negotation to serve the user agent's capabilities?



>
>
>> Content negotiation is supposed to be for client software to advertise
>> what formats it supports so that the server can provide suitable content
>> which can be displayed by the host software.
>>
>
> Content-negotiation is on server side (and displayed on client side)
>

http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html


>
>
>>
>> It's not really meant for authors to declare what content they want
>> requested - if you already know the distinct resource you want to
>> reference, you should just link to it. Then the client will either support
>> the format and display it, or not and offer it for download.
>>
>>
> Same URL offers multiple representations (I don't like multiples URLs for
> same resource, based on their representation):
>
>     http://server.com/account/12345  (can be represented as XML, JSON and
> downloaded as PDF for example)
>

Yes, the resource may have multiple representations but they are all
representations of the same resource. The content-negotiation is for
supporting user agent capabilities, not as a means to multiplex formats.

If the representation is an entity in it's own right, it should have it's
own URL. Otherwise people will be unable to access it.


>
>     I think multiples URLs, for same resource, is very ugly
>
>      · http://server.com/account/12345.htm
>       · http://server.com/account/12345.xml
>      · http://server.com/account/12345.json
>      · http://server.com/account/12345.pdf
>
>
The aesthetics of URL design is quite subjective.



>
>
>> Overloading resource URLs on the server and overriding Accept headers on
>> every link goes against some basic web principals.
>>
>
> I override "accept" header only on some links (when I request concrete
> representation) by default every link uses browser default headers
>
>

It is this case which is a problem. The link, depending on whether it was
clicked on in the document, or typed into the location bar, will give
different resources.

While it might serve your URL design, i don't think it benifits users who
would find this kind of behaviour confusing.

Cameron



>
>>
>> Cameron
>>
>>
>>> On Wed, Jun 18, 2014 at 5:28 PM, Cameron Jones <cmhjones@gmail.com>
>>> wrote:
>>>
>>>> On Mon, Jun 16, 2014 at 6:15 PM, Jose Antonio Illescas del Olmo <
>>>> jose.illescas@gmail.com> wrote:
>>>>
>>>>> And links?
>>>>>
>>>>>    <a href="/formula">link</a>
>>>>>
>>>>
>>>> Anchors are static references to URLs, whereas forms are used for
>>>> configuring custom scheme requests. They both serve a distinct purpose so
>>>> mixing the necessary complexity into anchors serves no purpose - if you
>>>> need to configure a custom HTTP request you can use a form.
>>>>
>>>> HTH,
>>>> Cameron
>>>>
>>>>
>>>>
>>>> Thank you, Cameron
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jun 16, 2014 at 5:57 PM, Cameron Jones <cmhjones@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Sat, Jun 14, 2014 at 11:53 AM, Jose Antonio Illescas del Olmo <
>>>>>> jose.illescas@gmail.com> wrote:
>>>>>>
>>>>>>> Please consider add (optional) "accept" header to request concrete
>>>>>>> representations:
>>>>>>>
>>>>>>> Until now is necesary delegato on extension to download concrete
>>>>>>> representations:
>>>>>>>
>>>>>>> For example:
>>>>>>>
>>>>>>>    Now: <a href="/resource.pdf"/>
>>>>>>>    Proposed: <a href="/resource" accept="application/pdf"/>
>>>>>>>
>>>>>>>    Now: <a href="/resource.svg"/>
>>>>>>>    Proposed: <a href="/resource" accept="image/svg+xml"/>
>>>>>>>
>>>>>>>
>>>>>>> The same attribute "accept" can be applied for <forms>
>>>>>>>
>>>>>>>     <form method="get" action="/formula"
>>>>>>> accept="application/mathml+xml">
>>>>>>>     ...
>>>>>>>
>>>>>>> Thank you
>>>>>>>
>>>>>>
>>>>>>
>>>>>> This feature is available within the HTTP Form Extensions
>>>>>> specification:
>>>>>>
>>>>>> http://www.w3.org/TR/form-http-extensions/
>>>>>>
>>>>>> You can configure a form using inputs which may override the standard
>>>>>> Accept header:
>>>>>>
>>>>>> <form method="GET" action="/formula">
>>>>>>     <input name="Accept" value="application/mathml+xml" type="hidden"
>>>>>> payload="_header"/>
>>>>>>     <button type="submit"/>
>>>>>> </form>
>>>>>>
>>>>>> Thanks,
>>>>>> Cameron Jones
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>