Re: Survey ready on Media Multitrack API proposal

On Thu, Mar 4, 2010 at 12:26 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Wed, 03 Mar 2010 21:11:32 +0800, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>
>> Replies inline.
>>
>>
>> On Wed, Mar 3, 2010 at 11:58 PM, Philip Jägenstedt <philipj@opera.com>
>> wrote:
>>>
>>> On Wed, 03 Mar 2010 18:45:28 +0800, Silvia Pfeiffer
>>> <silviapfeiffer1@gmail.com> wrote:
>>>
>>>> On Wed, Mar 3, 2010 at 5:35 PM, Michael(tm) Smith <mike@w3.org> wrote:
>>>>>
>>>>> A survey is ready on the "Media Multitrack API" draft change
>>>>> proposal.
>>>>>
>>>>>  http://www.w3.org/2002/09/wbs/44061/multitrack-api/
>>>>>
>>>>> The survey asks you to evaluate the proposal, which is for a
>>>>> JavaScript API for extracting basic information about tracks
>>>>> contained inside a media (audio or video) resource, and indicate
>>>>> whether you support submitting it to the HTML WG as a decision
>>>>> from the a11y TF; it also provides you with an opportunity to
>>>>> suggest changes to the proposal, and, if you indicate that you
>>>>> don't support submitting the proposal to the group, asks that you
>>>>> provide a comment giving your reasons.
>>>>>
>>>>> Only members of the HTML Accessibility Task Force can complete
>>>>> this survey. It is only a straw poll of the members of this task
>>>>> force. However, note that the results are publicly visible:
>>>>>
>>>>>  http://www.w3.org/2002/09/wbs/44061/multitrack-api/results
>>>>>
>>>>> --
>>>>> Michael(tm) Smith
>>>>> http://people.w3.org/mike
>>>>
>>>>
>>>> Hmm, it seems there is more discussion to be had about this proposal.
>>>>
>>>> I'd like to address Philip's concerns, so we can move forward.
>>>>
>>>>> The MediaTrack interface:
>>>>> * Drop role unless it is actually exposed in exactly that way in
>>>>> existing
>>>>> media formats, or describe how it can be derived from the
>>>>> information in existing media formats. Describe what value it should
>>>>> have
>>>>> when the information is not available (null or the empty
>>>>> string?)
>>>>
>>>> There will be a need to map from existing media formats to this role,
>>>> indeed. IIUC (and Eric or David can correct me), both QuickTime and
>>>> MPEG-4 expose certain information that relates to the roles that we
>>>> are describing. However, it is a text field and values have not been
>>>> pre-defined, so conventions will need to be used to map to our defined
>>>> roles.
>>>
>>> I'll leave it to Eric to comment on the details, but it sounds like role
>>> should just be a free-form string, just that UAs won't attach any
>>> behavior
>>> to unrecognized roles.
>>
>> It believe it already is a free-form string, but with some default
>> roles defined - those roles that made sense. We had a discussion about
>> this at the subgroup teleconf, btw, and agreed that it makes sense to
>> pre-define a set of roles so as to make the obvious roles
>> interoperable. Do you disagree with that proposal?
>
> What I'm saying is that whatever is in the media resource gets exposed as is
> in the API, i.e. the UA makes no attempt to map things to any of the
> predefined values. But this only works if all interesting container formats
> already have something like role and the identifiers used are the same as
> the ones we want in HTML5.

I think just displaying whatever value the container has defeats the
purpose of a standard API. It will result e.g. in several different
means of identifying "caption" - some would have "CC" others "cap"
others "caption" and there are certainly many other ways of specifying
it.

I think the purpose here is to expose to the Web developer a standard
means of identifying what is in the file. This mapping should be done
by the media subsystem that knows both the media file format and the
HTML standard and can provide for the mapping. It should only expose
directly what the file format stores if it doesn't understand the
name. Otherwise the task of mapping is left to the Web developer and
they would need to develop it for all possible media formats and all
possible naming schemes in order to get to a standard naming.

I think the media subsystem should do a best effort and then leave the
Web developer to sort out the hard problems.

Cheers,
Silvia.

Received on Wednesday, 3 March 2010 20:35:02 UTC