On Mon, 17 Nov 2008 m...@mykanjo.co.uk wrote:
>
> I've read that HTML5 will be providing markup for the PUT and DELETE
> methods. This is definitely good news - but I considered something else
> recently that, from what I can gather, is not in the current spec for
> HTML5; markup for specifying
Hallvord R M Steen wrote:
I've built two-three websites that use content/language negotiation
and I now consider it an architectural mistake to rely on negotiation
because the URLs no longer uniquely identify the variants I in many
scenarios need to identify. It's OK-ish to do it as a pure forma
On Wed, Nov 19, 2008 at 2:22 PM, Mike <[EMAIL PROTECTED]> wrote:
> Thomas Broyer wrote:
>>
>> On Tue, Nov 18, 2008 at 11:52 AM, Mike <[EMAIL PROTECTED]> wrote:
>>
>>> Thomas Broyer wrote:
>>>
On Mon, Nov 17, 2008 at 6:31 PM, <[EMAIL PROTECTED]> wrote:
> - The HTML version of that URL
> If you want to precisely identify the PDF *representation* (version) of that
> *resource* (document), you need the URI and your Accept headers set
> correctly. To that end, the solution to this problem would be to put
> example.com/document into a PDF reader.
>From a usability stand point, that
Thomas Broyer wrote:
On Tue, Nov 18, 2008 at 11:52 AM, Mike <[EMAIL PROTECTED]> wrote:
Thomas Broyer wrote:
On Mon, Nov 17, 2008 at 6:31 PM, <[EMAIL PROTECTED]> wrote:
- The HTML version of that URL could provide the web page representation
*and* provide links to all the other
On 18 Nov 2008, at 16:41, Joshua Cranmer wrote:
(and if you retort XMLHTTPRequest, let me point out that I
personally would have objected to injecting HTTP specifics into that
interface, had I been around during the design phases)
XMLHttpRequest doesn't need to be XML, it doesn't need to b
Joshua Cranmer wrote:
Mike wrote:
The benefits? Oh I don't know.. a markup language that supports the
transfer protocol it runs on?!
Who says you have to serve HTML over HTTP? I see it served via email
(and newsgroups), local filesystems, and FTP on a regular basis.
Indeed, making HTML depend
Mike wrote:
The benefits? Oh I don't know.. a markup language that supports the
transfer protocol it runs on?!
Who says you have to serve HTML over HTTP? I see it served via email
(and newsgroups), local filesystems, and FTP on a regular basis. Indeed,
making HTML depend on HTTP-specific featur
Hallvord R M Steen wrote:
"It's less typing" - Is that serious or are you joking?!
Isn't it? :)
Well sure, but I still don't know if that was a joke or whether it was a
serious point!
A bit of both. It's not an important point by any means, though I
think less verbosity
On Tue, Nov 18, 2008 at 11:52 AM, Mike <[EMAIL PROTECTED]> wrote:
> Thomas Broyer wrote:
>>
>> On Mon, Nov 17, 2008 at 6:31 PM, <[EMAIL PROTECTED]> wrote:
>>>
>>> - The HTML version of that URL could provide the web page representation
>>> *and* provide links to all the other content types availab
Mike writes:
> Smylers wrote:
>
> > [EMAIL PROTECTED] writes:
> >
> > > "... it'd be faster just to send the URL of the page which
> > > contains hypertext links to all the formats; at which point we no
> > > longer care whether those links specify the format in the URL or
> > > elsewhere."
> > >
Hallvord R M Steen wrote:
Sorry, both as an author and as a user I'd prefer this:
http://example.com/report";>html report
http://example.com/report.pdf";>pdf report
http://example.com/report.xhtml";>xml report
- Keep It Simple. For me as an author it's less typing, and for me as
a computer-liter
>> Sorry, both as an author and as a user I'd prefer this:
>> http://example.com/report";>html report
>> http://example.com/report.pdf";>pdf report
>> http://example.com/report.xhtml";>xml report
>>
>> - Keep It Simple. For me as an author it's less typing, and for me as
>> a computer-literate end
Smylers wrote:
[EMAIL PROTECTED] writes:
"Would the sender of that link necessarily know all the formats the URL
provides? Anyway, that's an unrealistic amount of typing -- typically
round here people just copy and paste a URL into an instant message and
send it without any surrounding text.
Thomas Broyer wrote:
On Mon, Nov 17, 2008 at 6:31 PM, <[EMAIL PROTECTED]> wrote:
Would the sender of that link necessarily know all the formats the URL
provides? Anyway, that's an unrealistic amount of typing -- typically
round here people just copy and paste a URL into an instant message
a
On Mon, Nov 17, 2008 at 6:31 PM, <[EMAIL PROTECTED]> wrote:
> > Would the sender of that link necessarily know all the formats the URL
> > provides? Anyway, that's an unrealistic amount of typing -- typically
> > round here people just copy and paste a URL into an instant message
> > and send it
[EMAIL PROTECTED] writes:
> "Would the sender of that link necessarily know all the formats the URL
> provides? Anyway, that's an unrealistic amount of typing -- typically
> round here people just copy and paste a URL into an instant message and
> send it without any surrounding text.
>
> Wherea
Hallvord R M Steen wrote:
as an example:
http://example.com/report";>html report
http://example.com/report"; Accept="application/pdf">pdf report
http://example.com/report"; Accept="application/rss+xml">xml report
Sorry, both as an author and as a user I'd prefer this:
http://example.com/re
> as an example:
> http://example.com/report";>html report
> http://example.com/report"; Accept="application/pdf">pdf report
> http://example.com/report"; Accept="application/rss+xml">xml
> report
Sorry, both as an author and as a user I'd prefer this:
http://example.com/report";>html report
http
[EMAIL PROTECTED] schrieb:
[...]
Please quote properly. Otherwise it's incredibly hard to follow
the discussion. Thanks.
Philipp Kempgen
"Would the sender of that link necessarily know all the formats the URL
provides? Anyway, that's an unrealistic amount of typing -- typically
round here people just copy and paste a URL into an instant message and
send it without any surrounding text.
Whereas without any other information, people
[EMAIL PROTECTED] writes:
> "It's also the most common case. Supposing I opened the above URL in a
> browser, and it gave me the HTML version; how would I even know that
> the PDF version exists?"
>
> Hypertext.
OK.
> "Except that in practice on receiving a URL like the above, nearly all
> user
"Except that in practice on receiving a URL like the above, nearly all
users will try it in a web browser; they are unlikely to put it into
their PDF viewer, in the hope that a PDF version of the report will
happen to be available."
I've adressed this subsequently:
'here's the URL: example.com/re
[EMAIL PROTECTED] writes:
> as an example:
>
> http://example.com/report";>html report
> http://example.com/report"; Accept="application/pdf">pdf report
> http://example.com/report"; Accept="application/rss+xml">xml
> report
>
> So I can send a colleague a message; 'you can get the report at
>
Hey Mike,
Good answers. :)
> The server is not obliged to respect the Accept header, there is nothing
> preventing the server from returning a gif even if the Accept header indicates
> solely png. This is actually the case with specifying content type in the URL,
> since there is nothing preventin
Just to clarify - I was suggesting that the type-less URI and Accept header
method was a better solution, not the
"example.com/report?type=application/rss+xml" example I gave.
Also; "including an optional header" should be "including an optional
attribute".
Sorry for any confusion!
Regards,
M
Adrian,
The server is not obliged to respect the Accept header, there is nothing
preventing the server from returning a gif even if the Accept header indicates
solely png. This is actually the case with specifying content type in the URL,
since there is nothing preventing example.com/index.html
On 17/11/2008 11:29, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Does anyone else agree that an Accept attribute would be a useful tool for
> making browser interaction more RESTful? Is it worth persuing this issue with
> the HTML5 working group?
I don't see why the Accept header when followi
Just to let everyone know that I posted the following to rest-discuss this
morning, any thoughts? :
I've read that HTML5 will be providing markup for the PUT and DELETE methods.
This is definitely good news - but I considered something else recently that,
from what I can gather, is not in the
29 matches
Mail list logo
