Re: interesting hash in URLs

Dear all, 
Raman has pointed out a very interesting new (to me) way of handling
fragIDs. Then he and others noted how the client-side handling of
fragIDs is underspecified in the Web architecture. While this may be
true, my first reaction was: what breaks? If nothing significant breaks,
why fix it?

So what does break? A client without scripting will not be able to
dereference that ID, for one, but under what circumstances is this a
problem? (And I don't see "you can't view it without Javascript" as a
real problem because Javascript has become a part of the Web for me,
just like PNG or Flash.)

The Web is poorer because CNN doesn't create first-class resources for
each of the pages that play the videos. I suspect the videos themselves
do have URIs without fragment IDs (I'm offline now, can't check), so the
issue is about the pages that play the videos. But one can still link to
the page that plays the video and the link will work in a browser.

Would have been better if they just made these URIs without the #/ part,
had the same page returned for all such URIs (should be a simple server
setting there) and the script within the page would just cut the last
part and do the same thing the current script does? But this would
require that server setting that the whole /video/* space returns one
single page, whereas now they just have the static page. Or they could
do the processing on the server, but I suspect they're trying to
off-load that.

Does anybody see a significant problem with this use of #? Any interop
problems, in particular?

Best regards,
Jacek Kopecky, a lurker

On Fri, 2007-07-27 at 16:18 +0100, Xiaoshu Wang wrote:
> T.V Raman wrote:
> > ab(use) --- often leads to the discovery of interesting if hacky
> > design patterns.
> >
> > One of the weaknesses in Web Arch is the relative weakness  with
> > respect to how client-side fragment identifiers are understood;
> > basically the early days of HTML said #idref --- and in some
> > sense nothing more has  realy been written down. Compare this to
> > the relative richness  in terms of how URL parsing on the
> > server-side is defined.
> >   
> I think Raman does raise an important question that needs to be 
> addressed by the Web Arch.  It is easier to understand how it works in 
> this particular web application, but what if the returned HTML document 
> contains an element that has the same fragment ID.
> 
> What is then the correct behavior, then? 
> (1) To scroll down to that element 
> (2) play the video 
> (3) Error message
> (4) Do nothing?
> 
> Of course a clearly defined meaning on fragment ID is needed.
> 
> A related fragment id meaning will come up when the content negotiation is considered.  For instance, what is the relationship between
> 
> a) get application/rdf+xml "http://example.com/exp/#something" 
> and
> b) get text/html "http://example.com/exp/#something"
> 
> And if the fragment id is not found by the client, is it like a 404 or somethingelse?
>  
> Xiaoshu 
> 
> 
>

Received on Monday, 13 August 2007 08:03:26 UTC