Hi Raphael.,
2010/2/10 RaphaÅ½l Troncy <raphael.troncy@cwi.nl>:
>
>> 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.
>
> As far as I remember, the main reason why we introduced the "s" was after a
> comment from Dave Singer that we should try to be Google syntax compatible.
> Is this not anymore a requirement we want to fulfill?
Yes, that's how I remembered it, too. But as Conrad noted earlier:
YouTube also uses "m" and "h" in their spec, so we shouldn't really
adapt an already well used npt scheme with partial features from
YouTube. Incidentally, YouTube's time offsets also work without the
addition of "s", so we really don't need to add the "s" to support
YouTube's scheme.
We should be able to resolve that today in the call. :-)
>> Other open issues from the last discussion on this were: marking
>> things "normative" and "informative", and the lack of error cases.
>
> I see two thread of discussions:
> â - Making up sections as normative vs informative. Honestly, I cannot see
> that happening before we are LC or CR.
If we can focus that on the key sections that I mentioned and the
steps I listed, it may be possible.
> â - Marking up sections as reasonably stable, mature, ready for test
> implementations, etc. ... which I think can be discussed tomorrow and should
> be out top priority.
That would be great.
I understood in last week's discussion that we cannot do this markup
without deciding what is normative and what is informative, thus the
mention of this activity, too.
>> 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).
>
> Yes, added in the agenda.
To help with the discussion, I have here listed some of the potential
error cases with 5.2.1. I have collected them from:
* the spec (5.1.5.
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-overview-errors)
and
* the wiki (http://www.w3.org/2008/WebVideo/Fragments/wiki/TestCases),
and added what I thought necessary.
Potential Errors for time dimension for URI fragments:
* Non-existent dimension: right now I'm only interested in dealing
with error cases for "t=", so let's assume that is in the URI fragment
* Non-errors: b>=a
t=a,b -> 200: set playback to a-b
t=a, -> 200: set playback to a-end
t=,b -> 200: set playback to start-b
t=a,b with a=b -> 200: set playback to a
t=a,b with a<start -> 200: set playback to start-b
t=a,b with a>end -> 200: set playback to end
t=a,b with b>end -> 200: set playback to a-end
t=a,b with b<start -> 200: set playback to start
* Validity errors: value cannot be parsed for dimension
example: t=asdf
-> 200: ignore fragment (retrieve full resource, but with this adapted URL)
note: browsers already do this
* non-existent
example: t=b,a with b>a (e.g. t=20,10)
-> 200: ignore fragment
* TC0001: undefined time segment - npt
example: t=,
-> 200: retrieve full resource, but with this adapted URL
(basically: ignore fragment)
note: browsers already do this
* TC0002: empty time segment - npt (see also above)
examples: t=0,0 ; t=3,3
-> 200: retrieve whatever the browser needs to set up playback and
set the playback position to the offset
NOTE: this is different to what we currently have at
http://www.w3.org/2008/WebVideo/Fragments/wiki/TestCases
* TC0008: legacy deep link
example: t=10
-> 200: return representation from second 10 on
Hope to discuss today!
Cheers,
Silvia.