Actions 138 & 139

Hi all,

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. I have also made some further
readability improvements. All of these I have documented below, so
feel free to give feedback. Also, I have a list of issues further down
in this email that came up as a consequence of doing this markup.

Read away at http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/

Here are the changes I made:

1.
Marked 5.1.2 as "This section is ready to implement."

2.
In 4.1 I have reformulated Philips paragraph about the EBNF being
disconnected from the parsing of the values of the fragment URI
components. Instead, it now refers to the parsing algorithm in 5.1.2
and 5.1.3.

3.
Marked 4.2.1.1 as implementable. Also removed the "s" from the npt
spec and adjusted the spec with the RTSP one (alas not the full RTSP
spec). I also referenced RTSP, so have taken Jack's comment out.

4.
Marked 5.2.1 as implementable. Added Eric's pictures and removed my
note requesting diagrams. I had to resize Eric's pictures, since the
<graphic> element doesn't allow me to scale dynamically by adding a
"width" attribute. :( I also added a sentence to try and capture
Conrad's statement that the graphs are just an example and reality
depends on the mime type. Change of wording suggestions welcome.


I have the following issues to discuss as a consequence of what I was doing:

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.

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?

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.

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?


Cheers,
Silvia.

Received on Wednesday, 17 February 2010 00:40:40 UTC