RE: What resource does this URL identify? - http://mail.google.com/mail/#inbox/11f804dfae358bd9

Thank you very much, David,

I was slightly surprised (and pleased) to hear the answer I wanted to hear.

At the risk of stating the obvious, let me describe the objections that
were raised within our teams. I'm not trying to argue against our own
solution, just trying to explain why the solution raised some anxiety and
controversy.

The user (or agent) starts with a "data URL" that identifies some reosurce.
In our domain, it might be something like a bug report. Asking for an RDF,
XML or JSON representation gives you pretty much what you would expect - a
bunch of information about the bug report, maybe its label, description,
creation date, a reference to the product that has the bug, steps to
reproduce etc. If you ask for a text/html representation, we return the
code for the AJAX defect-tracking client, along with enough information to
let it open on the right defect, which is likely just the original data URL
on which the AJAX code will perhaps perform a second GET this time asking
for a JSON representation. The objection that was raised here was "how can
all that AJAX code be considered a representation of the defect? Where is
the 'representational state'?"

If our teams should not be worrying about this objection - and maybe we
aren't the only ones getting wrapped around this axle - maybe the TAG could
offer some more explicit published guidance? When explicit guidance seems
thin, and when we see TAG emails suggesting that maybe content negotiation
should even be deprecated, it doesn't make our teams feel secure in their
design choice.

Best regards, Martin

Martin Nally, IBM Fellow
CTO, IBM Rational
tel: (949)544-4691



                                                                           
             "Booth, David (HP                                             
             Software -                                                    
             Boston)"                                                   To 
             <dbooth@hp.com>           Martin Nally/Raleigh/IBM@IBMUS,     
                                       "www-tag@w3.org" <www-tag@w3.org>   
             02/25/2009 08:56                                           cc 
             AM                                                            
                                                                   Subject 
                                       RE: What resource does this URL     
                                       identify? -                         
                                       http://mail.google.com/mail/#inbox/ 
                                       11f804dfae358bd9                    
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Martin,

FWIW, your solution does not look like a hack to me.  It looks like a
perfectly valid use of content negotiation that conforms to the
Architecture of the World Wide Web.  I would particularly point to section
3.2.2 on fragment identifiers and content negotiation, which states:
http://www.w3.org/TR/webarch/#frag-coneg
[[
The representation provider decides when definitions of fragment identifier
semantics are are sufficiently consistent.
]]
Though not directly applicable to your use case (because you are choosing
to use a URI without a fragment identifier), I think the principle is the
same: the provider gets to decide when two representations are sufficiently
consistent, and in your example it seems clear that the URI is identifying
an email message, regardless of how it is rendered and what other
information may be rendered along with it.

If others think this is an abuse of web architecture, I would be interested
to know exactly what conflict they see.



David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Statements made herein represent the views of the author and do not
necessarily represent the official views of HP unless explicitly so stated.


> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]
> On Behalf Of Martin Nally
> Sent: Monday, February 23, 2009 11:52 PM
> To: www-tag@w3.org
> Subject: What resource does this URL identify? -
> http://mail.google.com/mail/#inbox/11f804dfae358bd9
>
> I was hoping for some guidance from this group on the basic
> web design question below. Perhaps what I'm asking for is
> unfair - you are not a free web app design service, after
> all, but I hoped I was asking a question that would interest
> you. Perhaps I asked too long a question - let me try a
> shorter version.
>
> Lots of people are writing AJAX user interfaces that execute
> in browsers. GMail is a well known one. GMail exposes urls
> that look like this:
> http://mail.google.com/mail/#inbox/11f804dfae358bd9. Entering
> this URL in a browser will open GMail on a particular email
> in my inbox (if you are logged on as me). Our experience is
> that when writing AJAX user interfaces this pattern of URL
> becomes common. Parsing this URL,
> http://mail.google.com/mail/ is the URL of the email client.
> inbox/11f804dfae358bd9 identifies the "view" and the email
> the client should initialize on. It seems simple enough,
> although you might ask yourself what resource this URL really
> identifies. Imagine for the purposes of my example that
> http://mail.google.com/11f804dfae358bd9 is the URL of the
> email - Google doesn't really expose this URL.
>
> Our problem is that we have lots of "data URLs" like
> http://mail.google.com/11f804dfae358bd9, all linked to each
> other - they form our "data web". In our case the resources
> are not emails, they are resources for our domain. If you get
> a hold of one of these URLs, you can always ask it for a
> representation in the form of RDF, JSON, XML etc. But if you
> are a human, what you really want to do is to get back into
> the appropriate AJAX client program initialized on the
> resource. All you have is the data URL, you don't yet know
> the media type, so you can't guess the URL of the right
> client program. We can see 4 options:
>
> 1) Try to make sure that humans never see data URLs like
> http://mail.google.com/11f804dfae358bd9 - they only see UI
> URLs like
> http://mail.google.com/mail/#inbox/11f804dfae358bd9. We
> thought about this but it seems impossible.
> 2) Provide humans with some sort of algorithm for converting
> http://mail.google.com/11f804dfae358bd9 to
> http://mail.google.com/mail/#inbox/11f804dfae358bd9. We
> thought about this too, and it seems like a mess.
> 3) Let content negotiation on
> http://mail.google.com/11f804dfae358bd9 return the right
> thing. There seem to be two obvious versions of this:
> a) Use a redirect to
> http://mail.google.com/mail/#inbox/11f804dfae358bd9. Now the
> users are exposed to both URLs and it is sure and certain
> that they will use the wrong URL next time they want to refer
> to the email, thus messing up the data web
> b) Return the email client with some trickery to initialize
> on email 11f804dfae358bd9. This works BEAUTIFULLY, but it
> seems a bit of a hack from a web architecture point of view
>
> So the only solution that seems to work looks like a hack.
> What do you recommend? The TAG issue is that the standard web
> model does not seem adequate to explain or give guidance to
> data webs with AJAX clients.
>
> If you have patience, here is another thought on this
> problem. In the standard web model, a conceptually clean
> approach would be to write the clients as browser plug-ins
> instead of as AJAX clients. Of course, nobody wants to either
> write or use plug-ins for this purpose, but you might think
> of the AJAX clients as being the moral equivalent of browser
> plug-ins except they are implemented in DHTML. The problem is
> that the standard model (or browser reality) doesn't give us
> a clean way of integrating these "DHTML plug-ins" into the
> normal request/response flow.
>
> Best regards, Martin
>
> Martin Nally, IBM Fellow
> CTO, IBM Rational
> tel: (949)544-4691
>
>
> Martin Nally/Raleigh/IBM wrote on 02/20/2009 11:39:10 AM:
>
> > I sent a version of this note 2 days ago, but it seems to have been
> > caught in the anti-spam filters. My apologies if you end up seeing
> > this twice. I also apologize in advance for the length of this email
> > - this is especially rude since I'm new to this forum. Noah and
> > Ashok know me personally, but for those who don't, I work in IBM as
> > the CTO of the Rational software brand which develops products and
> > services to support our customers' software development needs.
> >
> > The recent exchange on the boundaries of content negotiation is very
> > near to a question we are stuggling with in IBM. You won't find any
> > brilliant insights from me to answer the question, but you will find
> > an explanation of why this question seems really, really important
> > to us right now. You will also find an appeal for help and advice.
> > You may be amused or horrified at my attempt at the bottom of the
> > email to justify the answer we want to hear despite the
> obvious objections.
> >
> > We are implementing products where the underlying data are exposed
> > as a web of resources accessed via HTTP. Our clients are implemented
> > using HTML and JavaScript in an AJAX style. Since both our data and
> > our UI are now on the web, we have the problem of how to relate the
> > two. We are aware that others have written about this topic - for
> > example we are aware of this document: http://www.w3.
> > org/TR/2008/NOTE-cooluris-20080331/. Unfortunately, the guidance we
> > are finding is not proving entirely satisfactory or relevant to our
> > situation, which is described below using examples from GMail and
> > YouTube.  We're not implementing email or video-sharing products at
> > IBM Rational, but the parallel to our own products is close enough
> > to illustrate the point.
> >
> > The base URL for Gmail is http://mail.google.com/mail/ which appears
> > to redirect to http://mail.google.com/mail/#inbox. Within your
> > inbox, you can click on an email - if you do, Gmail will open your
> > email and the browser address bar will change to something
> like this:
> > http://mail.google.com/mail/#inbox/11f804dfae358bd9. An improbable
> > number of POSTs and GETs go on under the covers before this URL
> > appears and none of them would make you expect that this URL would
> > appear, but somehow it does - GMail is not simple. Security will
> > hopefully stop you from following this link to this email, but I can
> > do it. So GMail provides me with URLs for each of my emails
> of the form
> > http://mail.google.com/mail/#inbox/11f804dfae358bd9, and it makes
> > those URLs appear in the address field, which is where users would
> > expect they would appear. That is fine if I'm a human that wants to
> > interact with GMail, but what if I'm a client that wants to get at
> > the email itself, not the GMail UI for the email? The products we
> > are working on must support both scenarios. One option that GMail
> > could implement is to offer a "link" button like the one in Google
> > Maps that Noah brought to my attention, but instead of putting the
> > "UI url" in there, it could put the "data url". In fact, YouTube
> > does something close to this - look at the content of the "embed"
> > field on a YouTube page - it includes the URL of the video separate
> > from the URL of the YouTube page that embeds the video.
> >
> > Just for the sake of an example, lets assume we, and GMail, did like
> > YouTube does, and assume the matching "data url" for the
> email above is
> > http://mail.google.com/11f804dfae358bd9. Am I now in good shape?
> > From one point of view, it's not bad, because I have both URLs for
> > my email, one for a UI for humans using a browser and a second one
> > for other purposes. If I can remember which URL is for which
> > purpose, always use the right one at the right time, always email
> > both of them to others, so they can do the same and so on, then it
> > works. Not only is this a pain, but uncaught mistakes will have
> > negative consequences, like defeating searches if the wrong URL is
> > stored in data or text. Much simpler would be to have a single URL
> > that just always did the right thing. This is why the pattern
> > documented here is attractive:  http://www.w3.org/TR/2008/NOTE-
> > cooluris-20080331/#r303gendocument. If we took this approach, we
> > would only need the "data URL" -
> http://mail.google.com/11f804dfae358bd9.
> > in the GMail example. If I pasted that into my browser, content
> > negotiation could get back the same HTML that is returned by real
> > GMail URL. On the other hand if I gave the URL to some other sort of
> > program that wanted an RDF repesentation or an XML representation,
> > content-negotiation would again give the right thing. This is a huge
> > improvement in usability of my solution.
> >
> > So why don't we just implement thisdesign? The objection, pointed
> > out by several of our developers (and me) is that it's a distortion
> > to say that the GMail HTML returned by  http://mail.google.
> > com/mail/#inbox/11f804dfae358bd9 is a representation of the email.
> > It's more reasonable to think of it as a JavaScript program that
> > turns around and does a bunch of further GETs and POSTs in whose
> > responses are somewhere buried a representation of the email. I'm
> > guessing this is why the authors of the paper cited above advised
> > against using content negotiation for this case - it seems like a
> > hack that is not in the spirit of the web architecture.
> >
> > The solution we are considering - and that we'd like some feedback
> > on - is to use content-negotiation despite the objections. This
> > design has by far the best characteristics from a user perspective.
> > If we had less delicate design sensitivities, we'd probably just
> > implement this and not worry about justifying it - perhaps we are
> > blind to problems this will cause later. Rather than pick a
> > different design with worse user characteristics in order to fit the
> > classic model, we choose instead to invent a justification for why
> > it's ok, as follows.
> >
> > "HTML started life as a language for representations of web
> > documents. Browsers were user agents that took HTML representations
> > of web documents, displayed them to users and allowed then to
> > navigate the web. This is still the basis of much of the web. Over
> > time, with the addition of forms, JavaScript and AJAX, HTML acquired
> > the capabilities of a full programming language and the browsers
> > acquired the characteristics of a programmable run-time environment.
> > Many modern HTML response documents are no longer representations of
> > anything that is meaningful to users. Instead of being
> > representations of resources that are interpreted by the browser
> > acting as a user agent, these HTML documents are implementations of
> > specialized user agents that execute in the browser as a run-time
> > platform. Given that HTML and the browser now have two distinct
> > meanings and roles - 1) document representations/user agents and 2)
> > implementations of specialized user agents/run-time platforms - we
> > permit our servers to take a more liberal view of the meaning of an
> > HTTP GET when the accept header includes text/html. Our server may
> > either return an HTML representation of the requested document, or
> > it may return the implementation of a specialized user agent
> > implemented in HTML for that resource."
> >
> > Please advise us. Is there another technical approach that we should
> > consider that has attractive characterisitcs for users? Is there a
> > better way of rationalizing the design choice that appears to work
> > best operationally?
>
> > Best regards, Martin
> >
> > Martin Nally, IBM Fellow
> > CTO, IBM Rational
> > tel: (949)544-4691
>
>