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

I believe that we can use the Content-location header in the response to
indicate that the response also has it's own separate URL. The URL in
content-location header will not appear in the browser address field, so
won't confuse our users, but provides some "truth in advertising" for
clients looking at the detail of the messages rather then the user
experience, which is the result of several AJAX message exchanges invisible
to the user.

Best regards, Martin

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



                                                                           
             "Booth, David (HP                                             
             Software -                                                    
             Boston)"                                                   To 
             <dbooth@hp.com>           Noah Mendelsohn/Cambridge/IBM@Lotus 
             Sent by:                                                   cc 
             www-tag-request@w         Martin Nally/Raleigh/IBM@IBMUS,     
             3.org                     "www-tag@w3.org" <www-tag@w3.org>   
                                                                   Subject 
                                       RE: What resource does this URL     
             03/02/2009 12:52          identify? -                         
             PM                        http://mail.google.com/mail/#inbox/ 
                                       11f804dfae358bd9                    
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
>
> > David Booth wrote:
> >
> > 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.
>
> and from an earlier note quoting AWWW:
>
> > The representation provider decides when definitions of
> > fragment identifier semantics are are sufficiently
> > consistent.
>
> [ . . . ]
> I agree David that, within limits, if a resource owner decides
> that a resource is such that two representations with somewhat
> different content are somehow both faithful representaitons of
> the resource, then conneg is OK. The real problem is that, in
> this case, Martin as the resource owner has made clear that he
> does not view these resources as the same.

True, but the point I'm trying to bring out is that,
contradictory as it may seem, these resources can be both the
same (when viewed at one level of abstraction) and different (when
viewed in more detail). The reason Martin wants
to use the same URI for all is that the users are *not* able to
make a distinction between them: from the user's perspective,
they are the same and can thus use the same URI, and Martin wants
to permit them to take this view. It is only when
you need to look in more detail, from the implementor's
perspective, that the differences need to be exposed.

I think this is similar to a situation in which a URI is used for
an abstract document that may either be served (in concrete form)
as PDF or as HTML, depending on content negotiation, but there
may *also* be separate URIs that specifically identify the PDF
and HTML versions. The resource owner chooses to expose the
generic URI so that the many users who don't care to separately
identify the PDF or HTML versions can use that, but other users
who do care to identify a specific format can use the specific
URIs.


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.

>
> Noah
>
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> "Booth, David (HP Software - Boston)" <dbooth@hp.com>
> Sent by: www-tag-request@w3.org
> 02/25/2009 01:57 PM
>
>         To:     Martin Nally <nally@us.ibm.com>
>         cc:     "www-tag@w3.org" <www-tag@w3.org>, (bcc: Noah
> Mendelsohn/Cambridge/IBM)
>         Subject:        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
> > >
> > >
> >
> >
> >
>
>
>
>