Re: [media] proposed a11y TF letter on issue-152

I would suggest a small change to replace the words 'However, we request' with the word 'with', so that the sentences run together and our proposal to withdraw 1-3 is somewhat contingent on the changes being agreed to proposal 4.

It's good that Ian is sympathetic to adding things exposed by media containers, but I don't agree we should be constrained by that: as I said, others (MPEG DASH) are looking to W3C to lead on these items and some (all?) of the proposed 'kinds' are really pretty straightforward and obviously useful.

...Mark

Sent from my iPhone

On Apr 21, 2011, at 7:48 PM, "Eric Carlson" <eric.carlson@apple.com<mailto:eric.carlson@apple.com>> wrote:


On Apr 21, 2011, at 7:15 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>> wrote:

Are you following the discussions on the main list and on whatwg? Ian mentioned there that he'd be open to add it if media resources exposed it. We could just insist on this change. It seems this is the only breaking point.

Will I then send off the email today as it was and we resolve it on the main list?

Yes, I think you should send it in as planned.

eric
Sent from my iPhone



Sent from my iPhone

On 22/04/2011, at 2:40 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:


On Apr 20, 2011, at 7:43 PM, Silvia Pfeiffer wrote:

I would personally think that we can resolve the 5 changes through the
bug tracker and that they are not substantial to be solved before LC.
They are "part of the plumbing" as John put it so nicely. But it is
indeed a good question whether turning the 5 changes into bugs would
be agreeable with other members of the group.

I disagree that the "track kind" is "part of the plumbing". Whether you can, or cannot, discover the types of tracks available from a script makes the difference (for me at least) as to whether this multi-track support is useful or not.

I would at least like to hear Ian's opinion on the "track kind" issue before agreeing that it can be dealt with as a bug, with the associated possibility that multi-track support goes into the LC draft without this feature. It's there for text tracks and I don't see any difference in rationale when considering audio and video tracks.

...Mark


Cheers,
Silvia.


On Thu, Apr 21, 2011 at 12:28 PM, Sam Ruby <rubys@intertwingly.net<mailto:rubys@intertwingly.net>> wrote:
On 04/20/2011 09:00 PM, Silvia Pfeiffer wrote:

We appreciate the extra time provided to us by the chairs to further
discuss the submitted four change proposals and come to an agreement.
There have indeed been lengthy discussions during the provided time
frame and we have made great progress.

Something to consider: think about what you could do if you had until May
14th...[1]

The group has come to a consensus on which proposal to support. While
some of our feedback on that change proposal has already been taken on
board, there is still a list of 5 outstanding changes that need to be
addressed for the specification text to be complete.

One way to proceed is to see if that number can be reduced between now and
Friday, and then to have a survey on the remaining items (asking for
objections to INCLUDING and objections to EXCLUDING each change).  The
results of the decision will affect what goes out in the Last Call.  The
standard for revisiting the decision would be New Information or a Formal
Objection.

Another way to proceed is to open bug reports on each and continue to work
on them until May 14th.  Changes over which there is WG consensus can be
made during that time.  Changes that reduce consensus can be reverted[2].

With the second approach, it still will be possible to raise issues and have
these issues resolved in time for HTML5 (as in CR, PR, and Rec). What you
gain if you go this way is a few more weeks to find WG wide consensus.  What
you lose is the opportunity to get these changes into the spec in time for
Last Call over objections should the chairs find that there to be stronger
objections to EXCLUDING these changes than there is to INCLUDING these
changes.

At this point, the issue has been raised and Change Proposals have been
written so the only way we will decide to close this issue and proceed with
bugs is if we have Amicable Consensus to do so.  If anybody objects to such
an approach, we will go with a survey.

- Sam Ruby

[1] <http://lists.w3.org/Archives/Public/public-html/2011Mar/0759.html> http://lists.w3.org/Archives/Public/public-html/2011Mar/0759.html

[2] <http://lists.w3.org/Archives/Public/public-html/2010Sep/0125.html> http://lists.w3.org/Archives/Public/public-html/2010Sep/0125.html