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

marking some sections as "ready for implementation"

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 3 Feb 2010 22:57:59 +1100
Message-ID: <2c0e02831002030357q46df9f9eyd6e01307e505cc41@mail.gmail.com>
To: Media Fragment <public-media-fragment@w3.org>
Hi all,

We have both Firefox and Opera waiting for a "go-ahead" from us on
what is ready for implementation and I don't really want to make them
wait, since I believe we can do with a reality check.

For this we should mark sections that we agree on as "ready to
implement". But to make that call, we need a group agreement.

I'd like us to move towards such a decision on the following sections:

Section 5.2.1, http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-UA-mapped
together with the specification part for NPT time:
Section 4.2.1.1
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#npt-time
and the general structure of media URI fragments.

One open issue here is the NPT time scheme, which currently has a "s",
which we discussed to drop in another thread and update the reference
to http://www.w3.org/TR/NOTE-datetime. Let's decide about this in the
next meeting, if we can and propagate the change into the spec.

Other open issues from the last discussion on this were: marking
things "normative" and "informative", and the lack of error cases.

We have scheduled to talk about error cases next week, so maybe we can
concentrate specifically on error cases for temporal URIs to complete
these in the spec (section 5.1.5 has a start).

I'd be happy to work over the spec for temporal URI fragments to mark
things normative and informative and "ready to implement" when we
think we're ready.

I believe what is required is to say basically:
* this is the specification of such temporal URIs using fragments (normative)
* when you get such a URI in a video element or in the URI bar, parse
it in this way (normative)
* then resolve it through byte range requests if you can (Firefox
already is able to do this for Ogg though it takes multiple byte range
requests to get to the right location; with new indexed Ogg files,
this will improve) (informative)
* the resulting display should be blah (informative)
* when you get these error cases, do blah (normative)

Hopefully I can get the go-ahead to prepare the "ready to implement"
markings by the end of next week's meeting.

Cheers,
Silvia.
Received on Wednesday, 3 February 2010 11:58:56 GMT

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