RE: change proposals for issue-152

> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
> Behalf Of Mark Watson
> Sent: Thursday, March 24, 2011 2:20 PM
> To: Silvia Pfeiffer
> Cc: public-html
> Subject: Re: change proposals for issue-152
> 
> 
> On Mar 24, 2011, at 8:57 AM, Silvia Pfeiffer wrote:
> 
> > Hi Mark,
> >
> > yes, you are right. I noticed that the in-band functionality was
> > missing the day after sending off the change proposal. Extension of
> > the existing tracks IDL attribute for in-band media tracks could
> > indeed solve this. I haven't fully thought through the
> > advantages/disadvantages in comparison to creating a new IDL attribute
> > of mediaTracks yet.
> >
> > I continue to believe that none of the existing proposals is perfect
> > yet but that continued discussion will resolve the remaining issues,
> > which are getting smaller and smaller.
> >
> > As for kind types: We did discuss the matter of track kinds that do
> > not fall within the given defined list. There was even a proposal to
> > introduce a registry. I believe that would be overkill. Instead, I
> > believe we should list the most common ones and allow other strings,
> > which will then be handled just like "metadata" on text tracks. Then
> > it is possible for browsers to experiment with further kinds and bring
> > them back into the spec as the list of kinds mature.
> 
> I agree. In DASH they use URNs for this kind of labeling, which does
> lead to unfortunately verbose names but at least enables people to
> create their own namespaces if they so wish.
> 
> In this context we could define some specific strings as is done for the
> text tracks and reserve all names beginning "urn:" for URNs.
> 
> I think the UA actually never needs to know what these strings "mean" -
> it's the application that will interpret them.

We've been looking at how inband metadata tracks can be labeled so that the application understands what type of metadata is in a particular metadata text track. Our thought was to leave "kind" = metadata and set "label" to a descriptive string based on other relevant specification, as suggested in step 2 of WHAT WG web-apps 4.8.10.12.2 Sourcing in-band text tracks. Setting "kind" instead, as suggested, would seem to be a reasonable alternative..

I agree that it seems the UA need never know what these strings mean, only how to generate them.

Bob Lund 
> 
> ...Mark
> 
> >
> > Cheers,
> > Silvia.
> >
> > On Tue, Mar 22, 2011 at 8:05 AM, Mark Watson <watsonm@netflix.com>
> wrote:
> >> Hi Silvia,
> >>
> >> In this proposal, how do I discover and control in-band tracks ?
> >>
> >> If I know in advance that a resource has, say, a sign language track,
> I can create a video element for that track and control its rendering
> that way. But in general I don't know this in advance: I need to be able
> to load the metadata for a resource and find out the tracks it contains
> (then I could create elements for the ones that I want). Or did I miss
> something ?
> >>
> >> A minor comment, but there are uses for the track "kind" which are
> not related to accessibility, for example directors commentary or
> multiple video viewpoints (most common with sports content).
> >>
> >> ...Mark
> >>
> >> On Mar 21, 2011, at 10:34 PM, Silvia Pfeiffer wrote:
> >>
> >>> Dear WG chairs,
> >>>
> >>> Please find a change proposal for issue-152: multitrack media API
> here:
> >>>
> >>> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposal
> >>>
> >>> Best Regards,
> >>> Silvia.
> >>>
> >>>
> >>> NOTE:
> >>>
> >>> This change proposal was created by a sub-group of the W3C Media
> >>> Accessibility Task Force. Many alternatives were looked at during
> >>> the process of creation of this change proposal (see [1]) and indeed
> >>> not all possibilities have been analysed to date. In fact, some of
> >>> the Task Force members are not in agreement with this proposal,
> >>> which has resulted in a second change proposal (see [2]). Further,
> >>> several members of the Task Force think that Ian's proposal (see
> >>> [3]) is also of high quality. It seems we just simply lack further
> >>> discussion time to arrive at a solution that everyone can agree to.
> >>>
> >>> [1] http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API
> >>> [2]
> >>> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposal_
> >>> 2 [3]
> >>> http://lists.w3.org/Archives/Public/public-html/2011Mar/0436.html
> >>>
> >>>
> >>
> >>
> >
>

Received on Thursday, 24 March 2011 21:15:09 UTC