Re: New Version of HashInURI

On Sat, 15 Jan 2011, ashok malhotra wrote:

> Please review http://www.w3.org/2001/tag/2011/01/HashInURI-20110115
>
> I updated the HashInURI document based on discussion on Thursday's call
> and a chat I had with Larry yesterday.    I also added a section on the Media 
> Fragments
> work that Michael Hausenblas recommended.

Some comments.

In 
http://www.w3.org/2001/tag/2011/01/HashInURI-20110115#ViolateW3CSpecs
<<
For HTML and XML the fragment identifier processing rules are defined in 
[RFC 2854] and [XPointer] respectively. The fragment identifeir is, 
essentially, a poin ter into a document and must match an element ID or 
"name". The CNN content stream is HTML and, thus, its fragment processing 
violates [RFC 2854].
>>
I disagree with that interpretation. From RFC 2854:
<<
    For documents labeled as text/html, the fragment identifier
    designates the correspondingly named element; any element may be
    named with the "id" attribute, and A, APPLET, FRAME, IFRAME, IMG and
    MAP elements may be named with a "name" attribute.  This is described
    in detail in [HTML40] section 12.
>>

I read it as "if the fragment value equals the id of one element, then it 
identifies that element".

In the CNN example, the fragment identifies designate no element, and that 
is fine; if it was identifying an element, it would generate a conflict 
between the element identified, and the JS code handling the fragment.

Also, still for the CNN example, modifying the behaviour using only the 
fragment allows caching, and pushing content through CDNs, which is a nice 
property.

In 2.2,
Retrieving fragments using time ranges (for time fragment) _may_ be done 
heuristically, like if the href is in a <video> tag. Also the time range 
will not apply to anything else than a video, which is the desired 
behaviour, and if there was a conflict, the response headers will indicate 
this right away (not the right content-type). The fact that most media 
types are not defining fragments in their registration is the key issue 
here, and needs to be addressed (but that is related to Larry's document).

Also there is a section 3 "Manipulating Browser History", but some text 
around the JS api to handle fragments is missing, like location.hash 
property, onhashchange event, that allows reactive code.

In section 5, I am wondering if the conclusion is to amend the definition 
in the media types that accept "active content" in them, like HTML and SVG 
to acknowledge tht fact that fragments might also be used (if not in 
contradiction with the 'static' use of those fragments) for programmatic 
purposes. So instead of just saying that there is a contradiction, 
identifying what has to change and where.

I don't get the point of section 6 "Affected Communities", especially as 
it doesn't list the media type registry procedure.

Cheers,

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

         ~~Yves

Received on Thursday, 20 January 2011 10:48:24 UTC