Re: ABNF for fragment syntax

On Thu, Mar 5, 2009 at 8:44 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
>
> On  4-Mar-2009, at 12:08 , Silvia Pfeiffer wrote:
>
> On Wed, Mar 4, 2009 at 8:21 PM, Raphaël Troncy <Raphael.Troncy@cwi.nl>
> wrote:
>
> Dear Silvia,
>
> I would say that is really up to the container format to define. We
>
> could recommend that there be a naming scheme such as video[0] ...
>
> video[n] and audio[0] ... audio[n] to address multiple a/v tracks,
>
> maybe even text[0] ... text[n]. But I don't think they make much sense
>
> - it would be better the names chosen had some semantic meaning, such
>
> as "video", "sign-language", "audio", "music", "speech",
>
> "sound-effects", "audio annotations", "subtitles-en", subtitles-de",
>
> "karaoke-en", "lyrics" etc.
>
>  And .. yes, at some point somebody should have some standard names
>
> for these - in particular for accessibility it would be nice to be
>
> able to say through the protocol "I want no audio tracks, but video
>
> and sign-language and all text tracks".
>
> Maybe there is a scheme that we need to develop, where the codec type
>
> is also part of the naming, e.g. video.sign-language,
>
> audio.annotations, video.music etc. We haven't thought much about
>
> structure for describing tracks yet.
>
> What do people think?
>
> It may be beyond our charter, but I think it is definitively something that
>
> is worth to note, investigate if not bring a solution. Silvia, what about
>
> creating an issue in the tracker recording exactly your message?
>
> Hmm, please do if you think it's worth it. I don't quite know how to
> go about it.
>
> My original question was "didn't we have a scheme for this, or did we drop
> that at some point", and reading this email thread I have the distinct
> impression that we had exactly this discussion in Gent, and that the outcome
> was that while it looks promising at first glance it becomes very
> complicated once you dig into it a bit more, and that we shouldn't do it.
>
> So, as I started this thread, let me now formally suggest that we do not
> implement anything along these lines. Any naming of tracks is purely up the
> the container format.

I think we need some standardisation in this field, otherwise it is
not possible to request only audio tracks etc. But the question is
whether we are the right people to introduce it.

I think there may actually be an argument for us doing it. We are
looking at standardising the addressing of URIs to media fragments.
Tracks and their specification are such fragments and being able to
select a track type through the URI would make life for a11y and e.g
also for search engines (that may only want the text tracks) much
easier.

I'd be prepared to look into this a bit more, if there are others
interested in it, too. I think we could come up with a really good
scheme that also allows direct addressing of tracks simply by name,
e.g. name.blah, as well as video.blah etc. Just some initial ideas
here. :)

Will cut-and-paste into the Issue once your email is in. :)

Cheers,
Silvia.

Received on Thursday, 5 March 2009 00:29:45 UTC