[whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers

[Smylers]

Mike writes:

> Smylers wrote:
> 
> > mike at mykanjo.co.uk 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."
> > >
> > > - The HTML version of that URL could provide the web page
> > > representation *and* provide links to all the other content types
> > > available.      
> >
> > Indeed it could.  In which case the original claimed advantage of the
> > recipient of the message being able to open a single URL in one of
> > several different sorts of user-agents is no longer relevant; the links
> > could specify the format in the URL and this'll work just fine.
> 
> You're completely missing my point here.

Sorry.

> I'm well aware that you can do conneg in the URL.

Good.

> HTTP provides a way to perform conneg at the protocol level;

Yes, I see that.

> no mechanism for this is currently provided by HTML.

And I see that as well.

What I'm missing is _why_ it would be advantageous to be able to do
this.

You originally suggested an advantage would be being able to have an
'ambiguous' URL, one which could provide a document in one of multiple
formats, and that passing such a URL to somebody else and enabling her
to download one of multiple formats of some content from that URL.

But we seemed to agree that in practice what would happen is the
recipient would load that URL in a browser to view the HTML format of
the document, and then, if she wants the PDF format she'd follow a link
in that HTML page.

So even though original URL _could_ have been opened in a PDF viewer,
that is never taken advantage of.

> Uniform *Resource* Identifier - different content types are different
> *representations*, not different resources.

That's certainly one possible interpretation, but I think treating
different formats of a document as different 'resources' is equally
plausible.

In practice web users don't often seem to use terms like 'resource' and
'respresentation'; they more commonly refer to 'documents', 'pages',
'formats'.  Two different formats of a document having two different
locations (and therefore implicitly being deemed to be two different
resources) isn't massively confusing for users, mainly cos they simply
don't think about the concept of what a resource is.

> Protocol level conneg was included in HTTP so that URI's would not
> have to be responsible..  unfortunately HTML didn't provide adequate
> mechanisms to make use of this - so everyone is used to conneg
> happening in the URI. That doesn't  make it 'the right way to do it'.
> Developers should be given the option.

What advantage would it be for a developer to do this?  As in why when
given the option would he choose to take it?

You've already pointed out that at least in the short term he'd have to
use both the URL and HTTP ways, so either way he'd always have to
provide the format selector in URLs.  Having done that, and it working
everywhere, he'd then have the option of either doing absolutely nothing
or of additionally doing some more work to do the same in HTTP.  Why
would he?

> > > HTTP provides conneg, why would you consciously deny developers
> > > the opportunity to use it in browsers?
> >
> > HTML 5 implicitly denies things merely by not providing them.  And it
> > provides things which are useful.  So the question actually needs to be
> > asked the other way round: what benefits are there in this being
> > supported?
> 
> The benefits? Oh I don't know.. a markup language that supports the  
> transfer protocol it runs on?!

That's circular: you're claiming the benefit of supporting this is so
that it is supported!  What's an actual advantage -- either a user
experience which is superior, or a situation in which developers would
choose to use it?

> This isn't a feature request - it's a bug. You're denying developers
> the ability to choose to use protocol level conneg.

True.  HTML 5 fails to provide developers the ability to do all sorts of
things.  That's only a problem for things which have real-world uses,
and I'm yet to grasp one for this proposed feature.

> > > "Not just browsers, as I pointed out.  Also many databases which
> > > have tables with URL fields would need extra fields adding."
> > >
> > > - I suggested the attribute should be optional, so it would make no
> > > difference; one would simply avoid using it if it was a big problem.
> >
> > If my database contains URLs of external websites, then it isn't under
> > my control as to whether this feature gets used.  If those sites start
> > using it, then my URLs are no longer sufficient to uniquely identify
> > what is downloaded, and I need to change my database schema (and
> > software that uses it) to remedy that.
> 
> They are completely sufficient, if you provided the link but with no  
> Accept attribute specified.. it would use the browser default (which is,  
> generally, html). So that's a non-issue; It's backwards compatible.

If some of the URLs in my database are supposed to be of PDF documents
then it is not backwards compatible if such URLs by default provide HTML
instead.

> > ... in order to make this change let's first show that the current
> > way isn't good enough.
> 
> It's not good enough because it's merging representations (conneg)
> into resources (URIs). This isn't the way HTTP was intended to be
> used, that's just what people are used to.

But why is that actually a problem?

> I'm not suggesting the current way of doing it should be abolished,
> I'm saying we should give people the choice. There is no choice at the
> moment

Choice isn't a goal in itself; often having multiple ways to achieve
something can be a disadvantage.  To do this we still need an advantage
of that choice.

> (aside from using JavaScript).

Are many sites currently using JavaScript for this?  That would provide
good evidence that developers want to make use of the feature, and would
choose to do so if exposed in HTML.

> You're forcing me to repeat myself alot!

I'm not forcing you to do anything.  I've read everything you've
written, so please feel free not to repeat any of your previous answers;
honestly, I'm asking these questions in the hope of getting additional
information from you -- mainly real-world scenarios.

> > > - I'll say it again: I'm encouraging you to help browsers become
> > > better HTTP clients; surely that is high on the agenda here..
> > > right?!
> >
> > Why?  That's tantamount to an appeal to authority.  Fully supporting
> > HTTP is a means rather than an end.  Are there situations in which
> > supporting this particular part of HTTP provides additional benefit
> > to users?  Or are there many instances of authors tediously coding
> > the same thing in JavaScript?
> 
> So you're taking the authority that the means you've chosen to
> provision are definitively superior to the alternative I'm proposing?

Not at all.  This is going to be possible using URLs whatever else we
decide, and there are sites already using it.  So this feature will be
implemented no matter now inferior it is.

However, for an alternative way of doing the same thing to be
implemented that will need to provide some advantage over the _status
quo_.

> I'm saying "lets do both and let developers decide".

I understand that.  But that isn't sufficient reason to add something to
HTML 5.  Suppose there were seventeen ways of donig this, all equally
plausible -- would you suggest HTML 5 defines all seventeen of them and
forces browser makers to spend time implementing them all?

For almost every feature throughout the entire spec people could suggest
at least one good alternative; adding them all would obviously double
the size of the spec (and therefore the implementation burden).

So let's not bother adding a features unless it confers some advantage.

> > Changes should have some real-world benefit, not just
> > bureaucratically complying with something for the sake of it.
> 
> Hyper Text Markup Language
> 
> Hyper Text Transfer Protocol
> 
> Why would you not do everything in your power to fully support the
> protocol every way you could?

I'd add things which are useful (or needed for backwards compatibility)
regardless of whether they are novel or in an existing spec.

> Am I missing something here?

That HTML 5 doesn't do appeals to authority, not even the authority of
other specs.

> > > If it mattered that much it would be a 2 second job to write a
> > > [wget] wrapper script of some kind..
> >
> > That does what?  A wrapper script which somehow contacts my web
> > browser (running on a different computer) to find out what the media
> > type is of the link that was most recently copied to the clipboard?
> >
> > Even if I could work out how to write such a script, why should I
> > have to?
> 
> Because you're complaining about having to do work to content
> negotiate with a *content neutral* HTTP client..

Yup, because it's work that I don't currently have to do.

> You're distracting from the discussion with this - it is possible to
> set the Accept headers with wget - let it go.

It's a disadvantage to the proposal.  On balance it may be worth this
disadvantage because it's more than outweighed by other advantages the
proposal brings.  But in order to judge that we have to be aware of the
advantages and disadvantages.

> > > wget is a developer tool it's not supposed to be convenient
> > > anyway.
> > 
> > So wget currently _is_ convenient for me.  And the defence of a
> > change which will make this significantly less convenient is that it
> > was my fault for finding it so convenient in the first place?!
> 
> Well I don't consider having to type 15-20 characters or so a massive
> inconvenience..

It isn't a _massive_ inconvenience.  But it is _an_ inconvenience, and
therefore deserves to be included in the decision-making.

> what do your personal reservations and your overly-specific use-case

How can a scenario be overly specific?  Specific examples are much
better at demonstrating real-world advantages and disadvantages.

But if you like, the scenario can be made less specific: copying a URL
is no longer sufficient to uniquely identify what gets downloaded.

> have to do with HTML5?

As many advantages and disadvantages as we can think of should be
considered -- including mine!

> > > "Or what about if I wanted to mail somebody pointing out a
> > > discrepency between two versions of the report, and wished to link
> > > to both of them.  That's tricky if they have the same URL.
> > > Possibly I could do it like you have with the wget command-line
> > > above, but that requires me knowing which browsers my audience use
> > > and the precise syntax for them."
> > >
> > > - separate versions are separate resources, not separate content
> > > types. That has nothing to do with conneg..
> >
> > I was meaning a difference between the HTML version and the PDF
> > version of the same content (or at least what is supposed to be the
> > same content) -- how would I link to them?
> 
> If they're the same resource they should contain the same
> information..  just in.. a different format..

Indeed they _should_; that's why in my scenario I wanted to point out a
discrepency between them, so that it can be remedied and both then serve
the same information.

For an example of somebody doing this see Simon Pieters's recent
message:

  http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-November/016999.html

Simon didn't include any URLs in his message, because its audience are
well aware of how to find those documents.  But it isn't hard to think
of a similar scenario in which it would be desirable to link to them.
(And note also that Simon refered to "the PDF version of the spec",
using the word "version" to mean "format", as I did above.  You may
disagree with that terminology, but it does crop up in real life.)

Smylers