RE: Track kinds

> Are there URIs which identify the name space, rather than the individual values ?

I believe they identify the individual values.

>http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-keyword
... 
>The only issue with URLs is that they are not guaranteed to continue to mean the same thing over time. Even domains can change ownership (even if that is unlikely for w3.org). The 3GPP/MPEG specification suggest including a year/month in URLs to avoid this problem.

What if this URL was dated to be:

http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#attr-track-kind-keyword or maybe
http://www.w3.org/TR/html5/2011/05/the-iframe-element.html#attr-track-kind-keyword 

As per most W3C specs we could then lock down and stabilize the URL at the Candidate Recommendation stage.

Personally I don't understand why your requirements (ie stability and dated info) leads you to believe the W3C should start to use URNs which is something the org has never done before.

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-----Original Message-----
From: Mark Watson [mailto:watsonm@netflix.com] 
Sent: Thursday, June 09, 2011 1:22 PM
To: Silvia Pfeiffer
Cc: Paul Cotton; Janina Sajka; Judy Brewer <jbrewer@w3.org> (jbrewer@w3.org); Philippe Le Hegaret (plh@w3.org); HTML Accessibility Task Force
Subject: Re: Track kinds

Sorry I missed the call yesterday.

The URIs for the 3GPP and DASH descriptors can be URLs or URNs. The idea is that the URI identifies a "naming scheme" for the kinds, rather than having a separate URI for each actual kind value. Are there URIs which identify the name space, rather than the individual values ?

For example
> http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-key
> word
and
> http://www.w3.org/TR/html5/the-iframe-element.html#dom-tracklist-getki
> nd

?

The only issue with URLs is that they are not guaranteed to continue to mean the same thing over time. Even domains can change ownership (even if that is unlikely for w3.org). The 3GPP/MPEG specification suggest including a year/month in URLs to avoid this problem.

Two other possibilities:
(1) W3C gets a top-level URN allocation (urn:w3c) and we define "urn:w3c:html5:track-kinds" for this.
(2) Use a FCD URN such as "urn:fcd:w3.org:2011:html5:track-kinds" which requires no registration procedures

Note that it's not sufficient for us to say to 3GPP "you can use these URLs ...". It needs to be defined somewhere that "these URLs are specified for the purpose of identifying the space of track kinds defined by W3C".

...Mark

On Jun 8, 2011, at 3:50 PM, Silvia Pfeiffer wrote:

> The URIs for the values that HTML5 supports currently are as follows:
>
> * "subtitles": textual transcription or translation of the dialogue 
> http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-key
> word-subtitles
>
> * "captions: textual transcription or translation of the dialogue, 
> sound effects, relevant musical cues, and other relevant audio 
> information 
> http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-key
> word-captions
>
> * "descriptions": textual descriptions of the video component of the 
> media resource, intended for audio synthesis when the visual component 
> is unavailable 
> http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-key
> word-descriptions
>
> * "chapters": chapter titles, intended to be used for navigating the 
> media resource 
> http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-key
> word-chapters
>
> * "metadata": tracks intended for use from script 
> http://www.w3.org/TR/html5/the-iframe-element.html#attr-track-kind-key
> word-metadata
>
> * "alternative": a possible alternative to the main audio or video 
> track, e.g. a different take of a song (audio), or a different angle
> (video)
> http://www.w3.org/TR/html5/the-iframe-element.html#dom-tracklist-getki
> nd-alternate
>
> * "description": an audio description of a video track provided as an 
> audio track 
> http://www.w3.org/TR/html5/the-iframe-element.html#dom-tracklist-getki
> nd-description
>
> * "main": the primary audio or video track 
> http://www.w3.org/TR/html5/the-iframe-element.html#dom-tracklist-getki
> nd-main
>
> * "sign": a sign-language interpretation of an audio track provided as 
> a video track 
> http://www.w3.org/TR/html5/the-iframe-element.html#dom-tracklist-getki
> nd-sign
>
> * "translation": a translated version of the main audio track 
> http://www.w3.org/TR/html5/the-iframe-element.html#dom-tracklist-getki
> nd-translation
>
> Cheers,
> Silvia.
>
>
> On Mon, Jun 6, 2011 at 3:34 PM, Silvia Pfeiffer 
> <silviapfeiffer1@gmail.com> wrote:
>> Hi Paul, Janina, Judy and Philippe,
>>
>> Note that we are tracking this in the wiki at 
>> http://www.w3.org/WAI/PF/HTML/wiki/Track_Kinds .
>>
>>
>> I think the reply should be along the lines of:
>> ---
>>
>> HTML5 indeed has specified names for track roles, which are called 
>> "kind" in HTML5.
>>
>> The current set of available text track labels in the HTML5 spec is [1]:
>> * subtitles
>> * captions
>> * descriptions
>> * chapters
>> * metadata
>> While 3GPP didn't ask about these text track names, we just want to 
>> make them aware of these, too, since some names overlap with the 
>> media names (such as captions and subtitles) and may therefore lead 
>> to confusion.
>>
>> The current set of available audio or video track labels in the HTML5 
>> spec is [2]:
>> * alternative
>> * description
>> * main
>> * sign
>> * translation
>> * "" (for none)
>>
>> The HTML5 accessibility task force is further pursuing the inclusion 
>> of the following audio or video track kinds [3]:
>> * subtitles
>> * captions
>> * clean audio
>>
>> The proposed track roles by 3GPP would then map to the HTML5 roles as follows:
>>
>> * 3GPP "main" --> HTML5 "main"
>> * 3GPP "supplementary" --> not required in HTML5
>> * 3GPP "alterante" --> HTML5 "alternative"
>> * 3GPP "commentary" --> HTML "alternative"
>> * 3GPP "dub" --> HTML5 "translation"
>> * 3GPP "captions" --> HTML5 "captions" (once added)
>> * 3GPP "subtitles" --> HTML5 "subtitles" (once added) Note that the 
>> last two refer to video with burnt-in text (i.e. open 
>> captions/subtitles).
>>
>> Some more information is available on this wiki page [4].
>>
>> There will be no URN to specify these names.
>>
>> We recommend that the 3GPP define their own names, since they may 
>> require more than what HTML5 requires. We therefore further recommend 
>> that 3GPP create a URN scheme for their own names themselves. There 
>> will be no URN for the W3C names, since they are listed in the HTML5 
>> specification and will be maintained there.
>>
>> [1] http://dev.w3.org/html5/spec/Overview.html#the-track-element
>> [2] 
>> http://dev.w3.org/html5/spec/Overview.html#dom-TrackList-getKind-cate
>> gories [3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12544
>> [4] http://www.w3.org/WAI/PF/HTML/wiki/Track_Kinds
>>
>> --
>>
>> Hope this helps.
>>
>> Cheers,
>> Silvia.
>>
>>
>>
>> On Mon, Jun 6, 2011 at 1:17 PM, Paul Cotton <Paul.Cotton@microsoft.com> wrote:
>>>> It's a management issue, so is in the hands of Judy and Philippe.
>>>
>>> I am not sure I understand why this is a "management issue".  Has the TF recommended how to answer 3GPP's questions?  If so has the proposed answer been surfaced at the WG level?
>>>
>>> /paulc
>>>
>>> Paul Cotton, Microsoft Canada
>>> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
>>> Tel: (425) 705-9596 Fax: (425) 936-7329
>>>
>>>
>>> -----Original Message-----
>>> From: Janina Sajka [mailto:janina@rednote.net]
>>> Sent: Sunday, June 05, 2011 6:31 PM
>>> To: Paul Cotton
>>> Cc: Silvia Pfeiffer; HTML Accessibility Task Force
>>> Subject: Re: Track kinds
>>>
>>> Paul Cotton writes:
>>>> What is the status of our efforts to compose a reply to the 3GPP questions?
>>>>
>>> It's a management issue, so is in the hands of Judy and Philippe. As you'll recall, Judy has been away on vacation this past week, and the week prior we were dotting i's and crossing t's on the various issues around LC publication.
>>>
>>> Janina
>>>
>>>>      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/015
>>>>>>> 6
>>>>>>> .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)
>>>>
>>>>
>>>
>>> --
>>>
>>> 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 Thursday, 9 June 2011 18:42:26 UTC