Re: LC Review of "Media Fragments URI 1.0" from MAWG

I'm just going through my open emails of the MF WG and came across
this. Has anyone ever replied to this analysis? I know we have changed
a bit since October, but have we actually replied?

Cheers,
Silvia.

On Fri, Oct 1, 2010 at 1:49 PM, Tobias Bürger
<tobias.buerger@salzburgresearch.at> wrote:
>  Dear Raphael, all,
>
> you asked for review of your LC document "Media Fragments URI 1.0" (working
> draft from 24.06.2010). I had a look at the document and do not have any
> substantive or critical comment on it. As you, from the perspective of the
> MAWG, we are mainly interested in the capabilities of the spec to identify
> and point to fragments of a resource, therefore I focused reading on the
> syntax part of the document.
> The MAWG suggests the usage of the Media Fragments URI 1.0 with its
> fragment-properties whose purpose is to identify a (named) fragment and its
> role wrt. to a media resource. I can not spot any defects or omissions in
> the syntax part of the spec - this part seems to be very well worked out!
>
> Nonetheless I would like to ask you to take up some of my following points
> to improve the readability of the whole document:
>
> Section 1 / Overall structure:
>
> What I miss in this section is an introduction to the structure and the
> content of the document that guides the reader through the document. It
> should briefly motivate each section, tell the reader what to expect from
> them, and also give hints on which section to read based on different
> interests in the specification (i.e. a reader might only be interested in
> the fragments URI syntax while another might be interested in the server
> implementation part of it). Having said that, the specification could more
> clearly seperate between the syntax and the implementation part.
>
> Furthermore I think the order of the sections could be changed as you could
> maybe group the sections related with the implementation. This means that
> you could move Section 4 (the syntax section) directly after Section 2.
> Another reason for the suggestions to move Section 4 is that in Section 3
> you describe how your specification shuld be interpreted and implemented in
> both user agents & servers. However, the reader does not know the details of
> the specification yet.
>
> Each section 2-7 would also benefit from short introductions themselves.
>
> You refer to RTSP in the first section without giving a pointer or
> explaining what RTSP is; this might not be known to all readers.
>
> Section 2:
>
> The beginning of your terminology section was slightly confusing for me as
> you state that "you use the term 'URI reference' as defined in..." and in
> the next sentence say that due to simplicity reasons you don't call "URI
> references" like that in your report. Therefore I suggest  to rather saying
> that you "use" the term as defined in RFC3986, you could say that you adher
> to the semantics of the term "URI reference" as defined in RFC3986.
>
> Section 3:
>
> I strongly agree to the editorial note in Section 3.6 from Silvia: A table
> detailing the conformance criteria would be helpful.
>
> Section 4:
>
> Again, the editorial note from Philip in Section 4.2 makes a valid point. If
> you foresee or allow in your specification that vendors should be able to
> extend it, then you should provide details about the extension possibilities
> or how the group thinks extensions should be implemented and specified. This
> goes along with the conformance criteria point from Section 3.
>
> Here I miss a discussion of the possibilities for combined use of the
> different dimensions or at least a pointer telling the reader that you
> discuss this in your Section 6.
>
> Section 5:
>
> Section 5.1.2 says that a user agent without knowledge of which bytes to
> request for a media fragment should "guess" what to request. How would this
> guessing look like?
>
> Section 6:
>
> Here you could give hints on how you expect user agents or servers generally
> should implement error handling.
>
> The headings in Section 6.1 could be more readable. What does "Empty"
> (6.2.2) mean?
>
> You often write that sth. "results in 206" -> here you should make more
> explicit that you talk about HTTP Status codes.
>
> 6.2.1, third line says "t=a, or t=a" seems to cotain an error.
> 6.2.1, eight line describes a case where b is beyond the end (e) of a media
> resource. You say that a 206 should be returned, however you might want
> servers or user agents to point out to this particular case, i.e. that the
> requested end of the interval is beyond the end of the media resource and
> thus cannot be requested. Do you foresee this somehow?
>
> Did you at any point in time think about the definition of specialized error
> codes that might be returned to different (mis-) usages of the syntax
> (similar to the status codes the MAWG defines in the API document)?
>
> Overall:
>
> What I maybe miss in the spec are explanations on how the Media Fragments
> URI 1.0 should be used in the use cases you describe in another document or
> for purposes mentioned in the Introduction, i.e., how should a "Semantic
> Web" guy use your URIs, why should he be interested in it, etc...
>
> To conclude, as said above, I have no substantial comments on the content of
> the spec. I hope that my comments are useful and I am looking forward to
> re-visit the final version of your document in the near future.
>
> Best regards,
>
> Tobias
>
> PS: Tracker, this is action-265,
> http://www.w3.org/2008/WebVideo/Annotations/track/actions/265
>
> --
> ================================================================
> Dr. Tobias Bürger         Knowledge and Media Technologies Group
> Salzburg Research                           FON +43.662.2288-415
> Forschungsgesellschaft                      FAX +43.662.2288-222
> Jakob-Haringer-Straße 5/III   tobias.buerger@salzburgresearch.at
> A-5020 Salzburg | AUSTRIA         http://www.salzburgresearch.at
>
>
>

Received on Wednesday, 2 February 2011 11:09:23 UTC