Re: Actions 138 & 139

Hi Silvia,

> In preparation for putting the document into a state that it can be
> implemented by browser vendors, I have fulfilled my actions 138 and
> 139. I have marked up sections as "ready to implement" where we agreed
> on and I have included Erics diagrams.

Great, thanks!
I agree that we start to see the limit of xmlspec as a tool for 
generating the spec. I'm considering more and more to shift to RecSpec 
(http://dev.w3.org/2009/dap/ReSpec.js/documentation.html). I might do 
that before our next face-to-face.

> 1.
> I think section 5.1.1 about standardisation should be moved to the
> top. Maybe in its own section after section 2. It should clearly
> explain the state of standardisation of current URIs and that URI
> fragment and query parameters are under the control of the mime type
> owner or the server software respectively. And that this is a
> recommendation for normalisation of the use of fragment and query
> parameters related to media resources. It involves regarding fragment
> and query values as strings of name-value pairs separated by "&",
> which builds on existing CGI parameter conventions. Mime type owners
> and server software developers are encouraged to use the
> specifications of this document in their implementations.

I agree with that. This is also related to ISSUE-13, 
http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/13

> 2.
> As I was reading, I noticed that section 5.1.3 should also be marked
> as "ready to implement", since it brings in the mapping from the
> parsed name-value pairs to the media fragment dimensions. This
> section, however, has a editorial note from Jack in it, which will
> make it look disputed rather than agreed. Can we have a discussion
> about this section at the next meeting to sort this out?

Yes, to have such a discussion if Jack is here.

> 3.
> I was considering adding the error cases of the time dimension (as
> mentioned in http://lists.w3.org/Archives/Public/public-media-fragment/2010Feb/0019.html)
> explicitly into section 5.1.5 as a subsection, but then Michael asked
> to allow him to review the use cases by this week. So I have
> refrained. Also, I suggest pulling 5.1.5 out of there and giving it a
> separate section, e.g. 5.4 or even a whole new section 6.

I agree for moving this into a new section 6. We need to decide what 
should go in the core spec regarding the test cases and what should be 
exhaustively described in the TC document.

> 4.
> Finally and most importantly, the part of the specification that is
> ready for implementation is now marked. But we actually have only a
> restricted recommendation on what e.g. a HTML5 Browser is supposed to
> do with such URI fragment data. Would it be the same in a media
> element as in the browser bar? I think we have some initial notes in
> section 5.1.4, but it's not really sufficient. We can make some more
> recommendations in here, or what is probably better: we should start
> discussions over at HTML5 to define what a media fragment actually
> means to a browser. We can describe the recommendation to introduce a
> highlight on the transport bar to signify the focused fragment and
> that the playback should pause at the end. But there may be a need to
> e.g. attach a event to the end of a fragment or something (e.g. so the
> pause can be overruled in JavaScript, or a ad can be launched or
> whatever). So, such a discussion will likely have to happen in the
> HTML5 group. How do you think we should deal with that?

Perhaps we should list first what are these other UA we are talking 
about. I'm happy to start this discussion today too.

Further, in the current version, we have the sections 3, 4.1 and 5.1.1 
marked as non-normative. I would like we comment this as I think it is 
way too early to provide such statements.

   Raphaël

-- 
Raphaël Troncy
EURECOM, Multimedia Communications Department
2229, route des Crêtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Received on Wednesday, 17 February 2010 09:58:46 UTC