W3C home > Mailing lists > Public > public-media-fragment@w3.org > December 2009

working over section 5 of the specification

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 14 Dec 2009 14:49:37 +1100
Message-ID: <2c0e02830912131949l27cc1e95kbec8c2b09f0970cd@mail.gmail.com>
To: Media Fragment <public-media-fragment@w3.org>
Hi all,

I have worked over section 5 and am documenting the changes here so
you can follow.

1. Media Fragments Standardisation (5.1.1)

I have renamed it from "Media Fragments Semantics" since it's all
about standardisation. The whole section 5 is now called "Interpreting
and Processing Media Fragments" which to me implies semantics.

2. General Setup section (now 5.1.2 and 5.1.3)

I have segmented out the random thoughts that we had into section
5.1.2 General Interpretation and 5.1.3 Error Handling. I have removed
the general processing approach, since it was redundant with all the
detailed processing now given in section 5.3.

The Error Handling section needs a lot of work and I've left Michael's
note in there, since he started structuring it.

3. Protocols for Media Fragment URI Resolution (section 5.2)

Here, I have stayed with the scenarios defined in section 3 and have
defined the key HTTP request and response headers that they will
require. These include all the things we had in this section
previously. Please note that I wasn't able to reuse the pictures -
they need updating.

5.2.1 just describes standard byte range requests, which sets the
scene and helps us to refer back to where necessary.

5.2.2 introduces the new Range units and absorbs the previous
"Single-Step Partial Get" section. Please read this one very
thoroughly, since I have actually tried to make it apply to any
dimension. It has to use multipart messages for this. There are plenty
of questions to discuss in this section - see all my editorial notes.

5.2.3 introduces the cachable retrieval means and absorbs the
"Dual-step Partial GET" section. Please read this one carefully, too,
since I removed the X-Accept-Range-Redirect header and the need to
deliver headers.

5.3. Describes the query case, which is simply a normal resource
retrieval, unless we want to add additional headers such as "Link" and

4. Conclusions section (section 6)

6 doesn't contain the discussion of pros and cons between the
Dual-step and the Single-step any more - it wasn't constructive. The
only thing that remains from the discussion is the qualification of
what existing media resources can actually take part in the schemes.
And that needs further work.

OK, ready for discussion now (it took 3 days rather than the estimated
few hours of editing!). Check out the latest version at
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/, in
particular the editor notes that we should go through in the next
meeting - enjoy reading!

Received on Monday, 14 December 2009 03:50:30 UTC

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