Re: HashInURI

  Hi Yves:
Thank you for your comments!
Section 2.1.3 comes from Raman's paper and I was hoping he would respond.

These are corner cases and I agree with your analysis.  We could remove these
points or we could add your analysis and move them earlier in the main exposition.
My slight preference is to remove them.

We also need to discuss the media fragments work in this section.
All the best, Ashok

On 11/30/2010 7:00 AM, Yves Lafon wrote:
> On Sun, 28 Nov 2010, ashok malhotra wrote:
>
>> I just checked in http://www.w3.org/2001/tag/2010/11/HashInURI
>> This is a combination of Raman's hash-in-url writeup and my earlier writeup on
>> Client-side Storage.  Please review and comment.
>
> In 2.1.3
> I see
> "What if the returned HTML contains an element that has the same fragment ID as the one being used as a client-side parameter? Who wins?"
>
> Why is that a conflict in the general case? It is a conflict when the processing the same fragment by different code paths affect the same things.
> In the case of HTML, if you have a js that scrolls the page to a place that is different than an existing idref, the there is a conflict.
>
> If the fragid is used to start a video and is an existing idref, then both are executed in parallel.
>
>
> Also I don't understand "Given that the fragment identifier leads to a subsequent request, who should process the error response if one should be raised by that subsequent request?"
>
> It is not in the general case, but in the specific case of the CNN example (which is a bit misleading here, as the conneg point above is more general), but the fact that is it depends on how the 'subsequent request' is generated, by the script? by the fact that it's an automatically retrieved content once added in the DOM tree of the encapsulated document?
>
>

Received on Wednesday, 1 December 2010 13:03:29 UTC