RE: Track kinds

What is the status of our efforts to compose a reply to the 3GPP questions?  

	ACTION: 	3GPP SA4 kindly asks W3C:

	1)	whether our hope to recommend use of W3C 'role' names, in our specification, seems achievable and reasonable, in your opinion;
	2)	your thinking on the set of names;
	3)	your schedule for defining at least a stable initial set of names; 
	4)	whether you will define a URN to identify the set you define.

/paulc

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: Monday, May 16, 2011 6:15 PM
To: Silvia Pfeiffer
Cc: HTML Accessibility Task Force
Subject: Re: Track kinds

Thanks for this clarification, Silvia.

Janina

Silvia Pfeiffer writes:
> Hi Janina,
> 
> that email was the only one that we received. It was Philippe 
> forwarding the request to the mailing list. Mark, however, mentioned 
> the existence of that email much earlier to us. Only after we chased 
> it up did Philippe forward it to us. So, it is indeed the request that 
> we need to reply to.
> 
> Cheers,
> Silvia.
> 
> On Mon, May 16, 2011 at 12:03 PM, Janina Sajka <janina@rednote.net> wrote:
> > 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.ht
> > ml
> >
> >
> >
> > Paul Cotton writes:
> >> > Is there a URI pointing to this request?
> >>
> >> See 
> >> http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0156.h
> >> tml
> >>
> >> 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)
> >
> >

-- 

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 Sunday, 5 June 2011 17:25:27 UTC