W3C home > Mailing lists > Public > www-tag@w3.org > February 2011

Re: HashInURI

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Thu, 10 Feb 2011 22:12:13 -0700
To: nathan@webr3.org
Cc: Yves Lafon <ylafon@w3.org>, Karl Dubost <karld@opera.com>, Ashok Malhotra <ashok.malhotra@oracle.com>, "www-tag@w3.org List" <www-tag@w3.org>
Message-Id: <20110210221213.f752954c.eric@bisonsystems.net>
Nathan wrote:
> In reality everything is a different resource? well without getting
> in to the semantics of this, because that statement is provably
> false, I'll take it at face value to mean that everything which the
> application provides a view of (or things which comprise a composite
> view), in which case I think you'll find every "resource" is defined
> by it's own unique URI, unless of course it's only available as part
> of a collection.

Here are two different resources:


We know they're different resources because URIs are opaque, and these
strings aren't character-for-character identical.  This is reality --
each user's feed is a separate resource, is it not?

OTOH, since # has special meaning, any HTTP client will treat those as
being the same resource, i.e. dereferencing either one will dereference
http://twitter.com/ .  This makes http://twitter.com/ the *one* resource
being dereferenced for *everything*.

> > 
> > In this case, the semantics of the mapping of http://twitter.com/
> > varies based on the nature of the fragment, which can only be
> > described as architecturally broken.
> >
> it maps to an application, are you telling me now that an application 
> must not do anything?

I'm telling you that architecturally, that's backwards -- what we have
here, instead of being Code-on-Demand, is Content-on-Demand.  The
former sends the content, along with instructions on how it is to be
rendered.  The latter sends the rendering instructions, along with some
instructions on how to find the content.  These are not the same style.

These two URIs can also map to the same application, without any naming


HTTP clients don't see those as the same resource, because there's no
fragment.  The semantics of the mapping remain static, and are not a
function of fragment contents.  They can even be handled by different
server processes, unlike with #! where they wind up being handled by the
same server process.

But, since those last two "proper" URIs are what get fetched anyway,
what's the point of imposing a round-trip to get there?  (That's a
rhetorical question -- obviously, such chicanery isn't needed when
proper architecture is followed from the get-go).

Received on Friday, 11 February 2011 05:48:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:09 UTC