W3C home > Mailing lists > Public > public-media-fragment@w3.org > February 2010

minutes of 2010-02-03 teleconference

From: RaphaŽl Troncy <raphael.troncy@cwi.nl>
Date: Tue, 09 Feb 2010 14:19:57 +0100
Message-ID: <4B7160FD.1020209@cwi.nl>
To: Media Fragment <public-media-fragment@w3.org>
Dear all,

I just realized the minutes of last week telecon hasn't been sent yet to 
the mailing list. The minutes are available for review at
http://www.w3.org/2010/02/03-mediafrag-minutes.html (and in text format
below). Thanks Conrad for having scribed.


       [1] http://www.w3.org/
              Media Fragments Working Group Teleconference
03 Feb 2010
    See also: [3]IRC log
       [3] http://www.w3.org/2010/02/03-mediafrag-irc
           conrad, davy, erik, silvia, thierry, yves, jack
           davy, raphael, michael

      * [4]Topics
          1. [5]1 Admin
      * [6]Summary of Action Items

    <trackbot> Date: 03 February 2010

    <scribe> scribenick: conrad

1 Admin

    PROPOSED to accept the minutes of the 27 January 2009 telecon:

    <silvia> +1

    <jackjansen> +1

    <erik> +1

    RESOLUTION: to accept the minutes of the 27 January 2009 telecon


    Thierry/Yves to look for the charter extension

    extension has not yet been granted, but should not be an issue --
    just w3 process

    Erik: submission of MTAP SI on Semantic Multimedia ongoing

    <tmichel> the extension should have discussed at last week W3M
    meeting, but is was not

    2. F2F meeting

    <tmichel> plh said it should be discussed this afternnoon

    Draft Agenda:

       [7] http://www.w3.org/2008/WebVideo/Fragments/wiki/FithF2FAgenda

    venue and location are booked by thierry and erik

    erik: over the next 2 weeks we will have to fill in the agend


    we have to go to last call in march, there is a lot to discuss, it
    will be important

    there will be 5 there, hopefully the others can attend via phone


    Raphael to fix the weird character in the spec document

    <scribe> CLOSED:


    3.1 Media Fragment URI syntax: (Yves)

    Bug in the npt specification:





    erik: we changed from abnf to ebnf (?) yves, is your action still

    yves: yes

    silvia: is there an issue with the change?

    yves: no, i am using abnf for other things, but i'm sure ebnf shall
    be similar

    silvia: then we only have the parsing issues dom mentioned, which
    are minor

    yves: the npt definition was not exactly correct, that was the only
    thing holding up the grammar

    silvia: yes, as discussed in email, just a small change

    yves: i will look at that before the f2f

    (but i will be away next week)

    3.2 Protocol for URI fragment Resolution in HTTP

    Erik: any problem with the changes proposed by Philip?

    silvia: no, they clarify things, they might have made the document
    structure more complicated. philip also proposed some changes to
    document structure but they make sense

    erik: i agree

    jackjansen, i would be against a structure where normative and
    non-normative are not separated. I would like them to be clearly

    silvia: we should put an overview table at the end of the document
    of what is normative and informative, rather than spreading it
    through the document. most of it is obvious, but it is important to
    put the info in one place

    jackjansen, the nice thing about a table is that if it indexes all
    the normative stuff, you can use it to find what you actually need

    jackjansen, not sure i like the idea that it should be clear from
    the wording, because then in non-normative text you have to refrain
    from using SHOULD, MUST etc.

    jackjansen, it should be clear from the layout which is which

    silvia, comments in-line about what is normative is not useful

    jackjansen, in SMIL spec, we put in text markers for people who use
    screen readers etc. (as well as colors)

    jackjansen, in the published document there are only text markers --
    the visual markers were not included

    silvia, make a note now, put these in if we come to committee draft

    jackjansen, the xml format we use has a way to distinguish
    paragraphs, so if we use that we can modify the layout in stylesheet

    thierry, distinguish in screen and aural?

    jackjansen, just use the xml to make a clear distinction between
    normative and informative text


      [11] http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-structure.html

    thierry: we should put a div with class="normative" or

    <scribe> ACTION: Erik to mark up the spec with normative and
    informative classes [recorded in

    <trackbot> Created ACTION-134 - Mark up the spec with normative and
    informative classes [on Erik Mannens - due 2010-02-10].

    thierry: do we also want to have text saying "this section is

    silvia, that can be part of the style

    silvia, i guess the table is already in the document, but a table at
    the end with a reference to the normative parts would be nice

    ACTION-123: Yves to come up with ABNF for header syntax

    <trackbot> ACTION-123 Come up with ABNF for header syntax notes

    erik: action 133 is ongoing

    yves: re: action 123, need to find the proposal from the archives

    Review of the complete Section 5.2.1 for group approval

    <scribe> postponed (we have not all yet reviewed it)

    erik, this should be done before the f2f

    silvia: i have read it and am happy with it, apart from minor issues
    in the ebnf; dom also suggested to put the ebnf syntax together in
    one place; maybe we should just repeat it all at the end

    silvia, he made a few changes to make it easier to read, along the
    lines of the html5 spec

    silvia: i'm happy with what he's done, i don't have any issues

    erik: ok, tbc

    3.3 Rendering of Media Fragments URI in UA:


    Silvia to draft a new subsection in the Section 5 regarding the
    rendering in the UI of media fragments, at least for the temporal

    silvia: i sent an email just before this meeting
    ... i've put a paragraph into section 5.1.4



    so basically the action is done

    silvia: davy, i've made a mention of spatial,track dimensions

    davy: ok, i'll work over that too

    jackjansen, i really like silvia's suggestion, but we should make
    sure that in the protocol we have enough detail to actually
    implement it

    jackjansen, which touches on issue 5, similar to silvia's note about
    the temporal domain, but in the spatial domain

    jackjansen, we should ensure that the server provides any
    information such as width, height etc. so that clipping can be
    implemented client-side

    silvia, we need to specify these things for each dimension, please
    add a paragraph

    jackjansen, also at the end of section 5.1.4, a very simple graphic
    of a timeline of a video playing would be handy to help with
    understanding the intention

    close action-130

    <trackbot> ACTION-130 Draft a new subsection in the Section 5
    regarding the rendering in the UI of media fragments, at least for
    the temporal dimension closed

    <scribe> ACTION: davy,erik to extend section 5 regarding spatial and
    track dimension [recorded in

    <trackbot> Sorry, couldn't find user - davy,erik

    <scribe> ACTION: erik to extend section 5 regarding spatial and
    track dimension [recorded in

    <trackbot> Created ACTION-135 - Extend section 5 regarding spatial
    and track dimension [on Erik Mannens - due 2010-02-10].

    <scribe> ACTION: davy to create a diagram of video timeline to
    explain temporal dimension [recorded in

    <trackbot> Created ACTION-136 - Create a diagram of video timeline
    to explain temporal dimension [on Davy Van Deursen - due

    <scribe> ACTION: jack to check that 5.1.4 is implementable using the
    protocol [recorded in

    <trackbot> Created ACTION-137 - Check that 5.1.4 is implementable
    using the protocol [on Jack Jansen - due 2010-02-10].

    3.4 Discovery of 'Track' and 'Named' fragments:

    silvia: nothing to discuss yet, this is being worked on in ogg

    3.4, 3.5 to be discussed later on

    5. TEST CASES: (Michael)

    erik: i'm in favour of making next phone conf all about test cases,
    for a whole hour

    silvia, last week we mentioned that the foms people would be keen to
    have an indication on which sections are fairly ready, and my
    suggestion was that section 5.2.1 can be implemented

    <Yves> the only indication of stability is publishing LC or CR

    conrad: perhaps we don't need to specify that the mechanism for
    handling client-side fragments involves http byte-range requests:
    just specify that "if the client can already seek over the network,
    honor this fragment syntax"

    silvia, last week we decided that rather than pulling out parts of
    the document which are stable, we simply mark within the document
    how mature each part of the document is, so implementers can go

    silvia, whereas last call etc. is really for the whole document; we
    don't want to hold back implementers

    Yves, the parts which are unstable may lead to changes in the parts
    we think are stable now

    silvia, unlikely as that section is really trivial

    jackjansen, that section has very little value with out parts of
    chapters 3, 4

    jackjansen, i like the sentiment about allowing implementers to
    start implementing stuff, but ...

    silvia, yes, but we have already been through section 3
    substantially, any changes will be minor

    jackjansen, i probably agree, but then even if we mark sections as
    "stable" we should specify that it may change anyway. we don't want
    to be editing for all eternity like the whatwg is doing

    silvia, we should start having implementations. we are really close
    to having the temporal stuff finalized, even though the headers etc.
    may still be under discussion

    silvia, if we keep working on the spec without any implementations,
    it's not going to move ahead in a reasonable amount of time

    jackjansen, if we mark these things as not "stable/unstable" but
    "reaonsably stable, mature" etc. that is fine with me

    silvia, "ready for test implementations" would be a useful

    erik: fine by me too

    4. ISSUES

    <jackjansen> conrad, I'd like a note "for test implementation" or


    erik: postpone non-active issues


    jackjansen, is a phone conference the best medium for discussing
    details of test cases?

    silvia, i agree -- we should prepare the group for the meeting re:
    test cases, but it is up to michael

    silvia, whether we prepare for the test cases next week or not, we
    should at least talk about it then


    erik: any news?


    all ongoing

    7. AOB


Summary of Action Items

    [NEW] ACTION: davy to create a diagram of video timeline to explain
    temporal dimension [recorded in
    [NEW] ACTION: davy,erik to extend section 5 regarding spatial and
    track dimension [recorded in
    [NEW] ACTION: erik to extend section 5 regarding spatial and track
    dimension [recorded in
    [NEW] ACTION: Erik to mark up the spec with normative and
    informative classes [recorded in
    [NEW] ACTION: jack to check that 5.1.4 is implementable using the
    protocol [recorded in

    [End of minutes]

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 Tuesday, 9 February 2010 13:53:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:44 UTC