Re: interesting hash in URLs

My primary goal in opening this issue for discussion ws not to
assert that something was broken, but rather:

A)     Check "what breaks if anything"?
and
B)      If nothing breaks, document the design-pattern so that it
doesn't break in the future.

Jacek Kopecky writes:
 > 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 
 > > 
 > > 
 > > 

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Monday, 13 August 2007 15:49:02 UTC