Re: Track kinds

Thanks, Paul, but your reference is a full week later than our Media
Subteam conversations on this topic during our 27 April meeting. I don't
know whether it matters, but I was hoping to reference an initial
contact for the record.

Media Subteam minutes below show discussion:
http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0354.html



Paul Cotton writes:
> > Is there a URI pointing to this request?
> 
> See http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0156.html 
> 
> Paul Cotton, Microsoft Canada
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
> Tel: (425) 705-9596 Fax: (425) 936-7329
> 
> 
> -----Original Message-----
> From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Janina Sajka
> Sent: Saturday, May 14, 2011 10:31 PM
> To: Mark Watson
> Cc: Silvia Pfeiffer; HTML Accessibility Task Force
> Subject: Re: Track kinds
> 
> Is there a URI pointing to this request?
> 
> 
> I was tasked at our last Media Subteam meeting to draft a response for W3 management to consider. It would be helpful to be able to point to the request. Did this come via David Singer? Perhaps in an email?
> 
> Thanks in advance.
> 
> Janina
> 
> Mark Watson writes:
> > 
> > 
> > Sent from my iPhone
> > 
> > On May 6, 2011, at 4:25 PM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>> wrote:
> > 
> > On Sat, May 7, 2011 at 9:16 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
> > 
> > On May 6, 2011, at 2:18 PM, Silvia Pfeiffer wrote:
> > 
> > On Sat, May 7, 2011 at 5:22 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
> > 
> > I also have a procedural question: do we consider that we have 
> > received the
> > 
> > liaison from 3GPP (mentioned on the above page) ? Are we going to 
> > answer it
> > 
> > ?
> > 
> > There should be an email by a 3GPP member with all the relevant 
> > requests to the WG list. I haven't seen one such.
> > 
> > I doubt the 3GPP staff will post to the list. They will send the 
> > liaison to the chair of the group, possibly via W3C staff members, and 
> > expect them to distribute it to the list. I imagine it is stuck somewhere in that path.
> > 
> > Unless that arrives,
> > there is nothing to reply to.
> > 
> > We can see that it has been sent from their minutes and we can see the 
> > text of the document in their archives, so we can at least prepare for 
> > its arrival ;-)
> > 
> > 
> > Do poke the chairs to forward it, or ask them to reply to it. It 
> > doesn't seem right for us to just go ahead and try to represent the 
> > HTML WG in a reply to the 3GPP WG.
> > 
> > 
> > Oh, I don't mean that this group should do any more than agree a proposal for what we should say in a potential reply. I don't have any sense for what formalities are necessary to get such a thing agreed as an _actual_ reply.
> > 
> > 
> > 
> > One question they ask is whether we will define a URN to identify the 
> > space of kind values defined by W3C. One advantage of doing that is 
> > that
> > 
> > these kinds are then immediately supported in 3GPP and MPEG adaptive
> > 
> > streaming manifests, which means that there *is* a media container
> > 
> > supporting those kinds (perhaps addressing one of the editor's 
> > concerns
> > 
> > about new kind values).
> > 
> > I don't think HTML needs these values as anything else but short 
> > strings that we now have.
> > 
> > Agreed.
> > 
> > If 3GPP and MPEG need them as URNs
> > 
> > No, they need a URN that refers to the codepoint space containing 
> > these values. But I notice W3C doesn't appear to have a top-level URN 
> > space. It could use urn:fdc:w3.org:2011....
> > 
> > Seems to make sense to me... would such a URN be useful for anything else?
> > 
> > Probably not.
> > 
> > 
> > 
> > The 3GPP and DASH specs allow you to tag a track with any number of "Roles"
> > - so it can be tagged with roles from this W3C space (if anyone 
> > defines a
> > URN) as well as equivalent roles from other spaces if necessary for 
> > some application.
> > 
> > - and they probably have a swag
> > more that they have proposed and will use
> > 
> > Not really - they'd prefer W3C to define some 
> > container-format-independent ones, as I understand it.
> > 
> > - it makes a lot more sense
> > to me for them to define these themselves.
> > 
> > They seem to think the opposite ;-) In particular it's been stated at 
> > MPEG that the W3C HTML a11y group has more a11y expertise than the MPEG group.
> > And there is nothing container-format-specific about this concept of 
> > track kinds. The abstract kinds and their definitions need to be 
> > defined somewhere with responsibility for all containers or for none, 
> > not in the groups focussed on particular containers. The containers 
> > (and HTML) just need to define how those kinds are labeled in their syntax.
> > 
> > Well, MPEG caters for a lot more than just the Web and the kinds 
> > required elsewhere may need to be a lot more diverse. So, I agree that 
> > they do well in looking to us for a11y related kinds and it's great 
> > that they want to pick up the ones that we define here, but I highly 
> > doubt that will be the end of their list.
> > 
> > 
> > Some of the kinds that
> > media containers will expose may just end up creating getLabel() text 
> > rather than be exposed in getKind(). Ogg already seems to have a few 
> > of those.
> > 
> > Agreed, but I think this is a symptom of having media container 
> > formats lead the definition of kinds: they define kinds which are 
> > either not very well-defined or not universally applicable and so we 
> > decide not to expose these over HTML because we want the HTML 
> > interface to be clean and well-defined. The best way to achieve that 
> > is to define these things in a container-independent place and ask the containers to align.
> > 
> > 
> > Well, we don't need anyone to align. All we need is a mapping, which 
> > your wiki page provides perfectly.
> > 
> > Yes, but a mapping does imply semantic alignment, which is the kind I mean.
> > 
> > That is, for there to be a mapping from Role X in container Y to clearaudio in HTML, the X has to mean the same as clearaudio, not something similar but awkwardly different.
> > 
> > If the names are identical, the
> > better so. It's ok when not everything that a container can contain is 
> > exposed to HTML. Only what gets exposed needs to be compatible. I 
> > think we're on the best way there anyway. :-)
> > 
> > 
> > Agreed.
> > 
> > ...Mark
> > Cheers,
> > Silvia.
> > 
> > 
> > 
> > Finally, we discussed the "commentary" kind here at Netflix and in the 
> > end
> > 
> > we are happy to have it dealt with simply as "alternative". I do think
> > 
> > though that in principle there could be other (UI-related) reasons for
> > 
> > exposing a new track kind than triggering default behavior or 
> > application of
> > 
> > user preferences. This is certainly the case for accessibility 
> > use-cases
> > 
> > where the UI to enable/disable a particular track could usefully be 
> > tailored
> > 
> > to the intended users of that track (for example, enabling/disabling 
> > tracks
> > 
> > intended for the blind or those with low vision should ideally not 
> > involve
> > 
> > complex visual UI elements).
> > 
> > OK. I think we'll cross that bridge when we get to it.
> > 
> > Cheers,
> > Silvia.
> > 
> > 
> > ...Mark
> > 
> > 
> > On May 3, 2011, at 10:12 PM, Silvia Pfeiffer wrote:
> > 
> > I understand the problem of additive/alternative tracks, too, and have
> > 
> > tried to approach it with markup before. However, I think this is
> > 
> > making something that is supposedly simple much too difficult. The
> > 
> > ultimate choice of active tracks has got to be left to the user. For
> > 
> > this reason, I think @kind (or getKind()) should only ever expose what
> > 
> > content is available in the track, but there should not be an
> > 
> > automatic choice made by the browser. It's up to the user to
> > 
> > activate/deactivate the correct tracks.
> > 
> > Before we dive into anything more complex, we should get some
> > 
> > experience with an implementation of multitrack and the roles. I don't
> > 
> > think we will have much to go by for making a decision beforehand.
> > 
> > Cheers,
> > 
> > Silvia.
> > 
> > 
> > On Wed, May 4, 2011 at 2:02 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
> > 
> > So, if we are looking for a generic approach, where a track can have
> > 
> > multiple "roles", then I think the correct logic is indeed to pick the
> > 
> > fewest number of tracks which fulfill the intersection of the desired 
> > roles
> > 
> > and the available roles such that no role is fulfilled more than once. 
> > You
> > 
> > need a priority list of roles to drop from the desired list if that 
> > isn't
> > 
> > possible (which would mean some badly authored content, but has to be 
> > dealt
> > 
> > with). It may be a mouthful, but I think it would be reasonably
> > 
> > straightforward to implement.
> > 
> > However, I'm still not sure a generic approach is necessary. A "simpler"
> > 
> > approach is to say every track has a single role. But for some 
> > applications
> > 
> > (like audio descriptions) there are two distinct role values defined - 
> > an
> > 
> > additive one and an alternative one. The problem is addressed at a 
> > semantic
> > 
> > level - i.e. people implement support for audio descriptions - and 
> > they know
> > 
> > what these are and how to handle them - rather than trying for a 
> > generic
> > 
> > descriptor matching algorithm.
> > 
> > Regarding Repetitive Stimulus Safe, I guess that since most content is
> > 
> > unfortunately not labeled one way or the other the default assumption 
> > has to
> > 
> > be up to the user themselves. i.e. that user preferences associated 
> > with
> > 
> > this aspect should support required, preferred and don't care. In a 
> > really
> > 
> > generic approach every role may have a status from { require, prefer, 
> > don't
> > 
> > care, prefer not, require not }.
> > 
> > Again, this suggests that a generic approach might be over-ambitious - 
> > who
> > 
> > says some new role doesn't come along next week with a sixth 
> > user-preference
> > 
> > status of "required unless role Y present" or similar ... I think 
> > maybe the
> > 
> > UA needs to understand what these things are and act appropriately.
> > 
> > ...Mark
> > 
> > 
> > 
> > 
> > 
> > On May 3, 2011, at 11:55 AM, David Singer wrote:
> > 
> > 
> > On May 2, 2011, at 16:55 , Mark Watson wrote:
> > 
> > 
> > I think it's evidence that there is something to be solved.
> > 
> > I'd prefer a solution where adding a track to an existing presentation
> > 
> > didn't require me to change the properties of existing tracks, though, 
> > since
> > 
> > there is an error waiting to happen in that case.
> > 
> > 
> > Yes.  This idea made some sense when it was the tracks in a multiplex (e.g.
> > 
> > MP4 file), perhaps makes sense when all the tracks are annotated in 
> > the
> > 
> > markup (e.g. in HTML5 or DASH MPD) but makes much less sense when some
> > 
> > tracks are in a multiplex and some are added in the markup - a track 
> > added
> > 
> > in the markup might need the annotations in a multiplex changed, ugh.
> > 
> > So, thinking out loud here.
> > 
> > Assume the user has a set of roles that they would kinda like to experience.
> > 
> > The default is 'main, supplementary', I think, or something like.
> > 
> > Now, we have a set of tracks, each of which satisfies some roles.  
> > Let's
> > 
> > ignore tracks we have discarded because they are the wrong mime type, 
> > codec,
> > 
> > language, etc., and focus just on this selection mechanism.  What is 
> > the
> > 
> > right simple way to get the set of tracks?
> > 
> > It's easy to 'go overboard' and treat this as a very general problem 
> > of
> > 
> > finding the minimal set of tracks that will span a set of design 
> > roles.  I
> > 
> > don't think anyone will author *for the same language*
> > 
> > track - main
> > 
> > track - captions
> > 
> > track - main +  captions
> > 
> > so an algorithm designed to pick only (3) instead of (1 + 2) for the
> > 
> > main+captions desiring user is probably overkill.
> > 
> > 'enable the tracks whose roles are a subset of the desired roles, and
> > 
> > disable the rest' may be too simple, unless tracks are ordered from 
> > the
> > 
> > most-labelled to the least-labelled.
> > 
> > So, audio-description replacing the main audio:
> > 
> > track - main description
> > 
> > track - main
> > 
> > Audio description adding to the main audio
> > 
> > track - main
> > 
> > track - description
> > 
> > The same works for all the adaptations that might require re-authoring 
> > or
> > 
> > might be achievable with an additional track (captions, burned in or
> > 
> > separate, for example).
> > 
> > 
> > Where this fails is when the 'base content' is good enough for both 
> > the
> > 
> > plain user and the user who desires more roles.  The obvious case here 
> > (Mark
> > 
> > will laugh) is repetitive-stimulus-safeness;  we have to assume 
> > unlabelled
> > 
> > content is unsafe, but much content is naturally safe and can be 
> > labelled as
> > 
> > such.
> > 
> > David Singer
> > 
> > Multimedia and Software Standards, Apple Inc.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> -- 
> 
> Janina Sajka,	Phone:	+1.443.300.2200
> 		sip:janina@asterisk.rednote.net
> 
> Chair, Open Accessibility	janina@a11y.org	
> Linux Foundation		http://a11y.org
> 
> Chair, Protocols & Formats
> Web Accessibility Initiative	http://www.w3.org/wai/pf
> World Wide Web Consortium (W3C)
> 
> 

-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@asterisk.rednote.net

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Monday, 16 May 2011 20:22:26 UTC