Re: Request feedback on fragment identifiers

Hi Larry,
Thanks for your prompt feedback, some comments/answers below,
Best regards
Myriam

Larry Masinter wrote:

>>For that, MPEG-21 could possibly define a fragment identifier for MPEG 
>>MIME types such as video/mpeg, audio/mpeg, and so forth. Then MPEG could 
>>also propose a Best Current Practise for other MIME-types which do not 
>>have an addressing scheme yet: The BCP could suggest the use of a 
>>generic fragment identifier scheme (at least, in MPEG-21) for any 
>>content type as long as there is no other authoritative addressing 
>>scheme. The BCP could also point to existing schemes, as for instance 
>>for PDF or XML resources.
>>    
>>
>
>I'm not sure how the PDF fragment identifier syntax or the
>XML fragment identifier syntax have much to do with
>MPEG-21 fragment identifiers.... For application/pdf, there's
>one MIME type with one syntax. For XML resources, there
>are two MIME types (application/xml, text/xml), and then
>a recommendation for what future MIME types might do.
>
>I don't like the idea of having a sort-of-recommendation where
>multiple interpretations might apply.
>
Ok, so if I understand well, you would not recommend to define a 
'default' fragment identifier syntax for MIME types that do not have one.
Instead, MPEG may define a syntax only for the MIME types it owns.
To be honest, technically, I still don't fully understand what are the 
limitations, but I'll report your recommendation to MPEG.

>And the XML recommendation isn't necessarily a good precedent;
>certainly there have been concerns about deployment for XPath,
>and how extensibility will work. I don't think it's sucessfully
>deployed.
>
>Without reviewing the MPEG-21 proposed scheme, I don't know
>whether to be concerned about verbosity, compatibility with
>fragment syntax, or compatibility with other addressing mechanisms
>(e.g., SMIL).
>  
>
Well, I could send you the spec if you wish, just let me know...

>>We didn't see anything in the RFCs that may exclude the use of a second 
>>fragment interpretation scheme other than an authoritative one that is 
>>registered with a particular MIME-type. However, this is an assertion we 
>>would like to cross-check with URI experts.
>>    
>>
>Not a very good line of reasoning ("nothing explicitly forbids this").
>
I agree, and that's why we contacted this mailing-list :-)

>How about you working through some of the compatibility scenarios.
>
>I get a pointer that says "Hey, look at this cool guy in this
>video!" and you send me a link with a wizzy new fragment identifier.
>
>I click on it, and, behold! I start watching the beginning of
>a boring video, because MY resolver doesn't know that you wanted
>me to seek to 30-minutes into the thing.
>
>So is this really a good idea?
>
Well, I'm a little puzzled. Isn't this inherent to the fragment 
mechanism and not to the syntax itself?
This is already true for example for an agent that does not support the 
svgView fragment, or the pdf fragment, and so forth.
Regardless of whether the agent is able to process the fragment syntax 
or not, the full content is always downloaded by the client:

"the optional fragment identifier, separated from
   the URI by a crosshatch ("#") character, consists of additional
   reference information to be interpreted by the user agent after the
   retrieval action has been successfully completed."

I guess that if you don't want to watch the 'boring video', you can just 
stop downloading or playing it.