- 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>
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
fragment.
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.
~~Yves
Received on Monday, 7 March 2011 14:39:07 UTC