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

Martin,

I think I understand the objection you describe, but I think it is based on an overly narrow interpretation of what a URI identifies.  Ultimately the information that the client gets is the same sort of information about the bug report.  In the HTML case, it just happens to be rendered via some AJAX code involving an additional GET.

Conceptually, this seems very similar to a page that contains some images.  Using content negotiation, the page might be rendered in PDF from a single GET (with the images embedded), or it might be rendered in HTML that contains image references <img src="...">, thus involving an additional GET for each image.   Ultimately the client gets the same sort of information, but in the HTML case some of the information is first included by reference, using <img src="..."> tags.

Make sense?  Does this help allay your team's concerns?


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: Martin Nally [mailto:nally@us.ibm.com]
> Sent: Wednesday, February 25, 2009 10:41 AM
> To: Booth, David (HP Software - Boston)
> Cc: www-tag@w3.org
> Subject: 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
>
> Inactive hide details for "Booth, David (HP Software -
> Boston)" <dbooth@hp.com>"Booth, David (HP Software - Boston)"
> <dbooth@hp.com>
>
>
>
>
>                               "Booth, David (HP Software -
> Boston)" <dbooth@hp.com>
>
>                               02/25/2009 08:56 AM
>
>
>
> To
>
> Martin Nally/Raleigh/IBM@IBMUS, "www-tag@w3.org" <www-tag@w3.org>
>
>
> cc
>
>
>
>
> 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
> >
> >
>
>
>

Received on Wednesday, 25 February 2009 18:58:49 UTC