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

Re: ACTION-178: Review the complete document, remove unnecessary editorial notes before publication (Media Fragments Working Group)

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 23 Jun 2010 18:47:45 +1000
Message-ID: <AANLkTilscgHg5BW8dEB-fXU7Dlb6BYw0-qJc-TTtZOvi@mail.gmail.com>
To: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
Cc: Media Fragments Working Group WG <public-media-fragment@w3.org>
2010/6/23 RaphaŽl Troncy <raphael.troncy@eurecom.fr>:
>
>> 1. RTSP
>> We had at some places mentioned that we support RTSP as well as HTTP
>> in this specification, but in particular section 5 (media frag
>> processing) we are completely focused on HTTP and do not mention how
>> the frag resolution could work over RTSP. We should either remove it
>> or add a section in 5 that explains how it is done with RTSP.
>> mention in:
>> * section 1
>> * section 2.2.2
>> * section 5.1
>
> I agree with Jack's opinion here. We have one one side the URL syntax which
> is common (Section 4) and on the other side the processing which is protocol
> dependent, nicely described for HTTP (Section 5). We could certainly add a
> section 5.3 (boiler plate to be filled) for processing media fragments on
> RTSP.

I would actually prefer to put a short section on RTSP in here rather
than ignoring the protocol processing part of HTTP. Section 5 is
generic enough to allow for any protocol to be described how it works
with the URIs we standardise.


>> 2. Caching
>> Section 3.4 states that in order to get the existing web proxy
>> infrastructure to cache media fragment resources, we need to use byte
>> ranges. In view of our recent changes - is that actually still true?
>> And what happened to section 7.4 - it's completely empty!
>
> Intentionally left blank :-)

"Intentionally left blank" is a blow in the face of everybody who sees
this section and thinks they can find out anything about how cached
media fragments work. It is not a sentence that should ever appear in
a specification that is supposed to be a standard.


>> 3. Requirements
>> Section 4 has an editorial note from Jack with a list of requirements.
>> I wonder if this list should go into the requirements document rather
>> than here? Or what part of it should indeed be kept here?
>
> I like this bulleted points but it should refer back to the UC &
> Requirements document. I suggest to add a note here.

These are done.


>> 4. ABNF unclear
>> Section 4.1 has the following bit of ABNF:
>> namevalues †= namevalue *( "&" namevalue )
>> namevalue † = name [ "=" value ]
>> name † † † †= fragment - "&" - "="
>> value † † † = fragment - "&"
>> I am curious what the role of the dashes and the ampersands is in the
>> name and value dimensions and why "fragment" is repeated there -
>> wouldn't it make a lot more sense to list the different names of the
>> dimensions? Also, these bits do not turn up in the summary ABNF at the
>> end - that is rather confusing!
>
> Has the clarification you wrote bee included?

This was a misunderstanding by myself. I haven't included a
clarification yet, but can do so.


>> 5. Clarify "track" dimension
>> I am rather confused right now: how did we decide to do multiple
>> tracks? In some places we talk about several tracks being able to be
>> defined, but only a single track per spec (see 4.3.3 and the
>> examples), and in other places we talk about there only being one
>> track dimension allowed (D.2 3c and 5.1.2, 5.1.2.1). Can somebody
>> clarify?
>
> We can have multiple tracks, see
> http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_URI_Syntax,
> resolution on 09/03/2010. All the places where we say we can have *only* one
> track should be fixed!

See other emails - we need to make sure it's consistent and described
in the spec.


>> 6. Clarify "id" dimension
>> I am again confused about "id". I was somehow under the impression
>> that we only allowed its use for the time dimension, but section 4.3.4
>> and 7.2 state that it can also be applied to tracks and regions. Also,
>> section 5.1.2 contains a editorial note by Davy about the same topic.
>> Did we actually clarify this and how it gets resolved?
>
> We purposely want to say that "id" can be anything (not only temporal) and
> CANNOT be combined with another dimension. An "id" refer to a part that an
> author has delimited in the media file, it could be spatio-temporal, it
> could be track for a period of time, etc.
>
>> I think because track names are already names, "id" will actually best
>> fit for temporal and spatial regions, but it would be cleanest to
>> simply allow them only for one dimension - otherwise, how are you
>> going to resolve it?
>
> No, we define the "id" as a convenient and human readable way of addressing
> fragment. Theoretically, there is nothing you cannot do if you remove this
> dimension. This is just a shortcut to a dimension or a combination of
> dimension that you might use so often that you want to give it a name.

Hmm... combination of dimensions. Interesting thought....

OK, I think I can let this one go.... but I'm sure it will come back
to haunt us. ;-)



>> 7. Error cases
>> Section 6 is incomplete. We need to discuss Raphael's note on 6.2.1
>> and my paragraph. We need to work on 6.3, 6.4, 6.5 for the
>> non-temporal dimensions.
>
> Agree. We will need to work on this in the coming weeks. During the Sophia
> Antipolis F2F meeting, we have even anticipate we might need a dedicated f2f
> meeting to progress on this in September/October. OVC @New York might be the
> good occasion!

Yup, a good idea. Shouldn't hold up the LC!


Cheers,
Silvia.
Received on Wednesday, 23 June 2010 08:48:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:39 GMT