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

Re: ACTION-481: HashInURI

From: Yves Lafon <ylafon@w3.org>
Date: Mon, 7 Mar 2011 09:39:05 -0500 (EST)
To: ashok malhotra <ashok.malhotra@oracle.com>
cc: "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <alpine.DEB.1.10.1103070850410.18492@wnl.j3.bet>
On Fri, 25 Feb 2011, ashok malhotra wrote:

> just checked in http://www.w3.org/2001/tag/2011/02/HashInURI-20110228.html
> Please review.  Especially sections 4,5 and 6.

In the introduction, it would be nice to reuse the definition of query and 
hash from rfc3986 (sections 3.4 and 3.5) like
    The fragment identifier component of a URI allows indirect
    identification of a secondary resource by reference to a primary
    resource and additional identifying information.  The identified
    secondary resource may be some portion or subset of the primary
    resource, some view on representations of the primary resource, or
    some other resource defined or described by those representations.

As it clarifies the different usages of fragments in the use cases.

In 4 Architectural Questions

The question of the accuracy of media type definitions of formats that 
allows active content (like JS) that can reuse components like the 
fragment. Usage evolved and HTML or SVG are not only static documents, 
which is the standpoint of both media type definitions when it comes to 

Another issue is the fact that it breaks some assumptions and usages, like 
"saving a page" as both Safari and Firefox are unable to save such pages 
and resume from the saved content. Obscurity of data access (how is the 
displayed data retreived, using GET or not, using HTTP or not (websocket 
or other), the shift between 'hypertext as the engine' and 'javascript 
and libraries' as the engine.

In 5, for the #!, should it become part of the media type and trigger 
specific browser behaviour (like on bookmarking, saving etc...)

Other comments soon.

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Monday, 7 March 2011 14:39:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:37 UTC