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

On Apr 21, 2011, at 9:02 PM, Silvia Pfeiffer wrote:

On Fri, Apr 22, 2011 at 1:14 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
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.

I do not think that any of the change proposals 1-3 are sufficient and
all of them are inferior to proposal 4, even as it stands now. I've
asked Eric about this, too, and both him and I are going to withdraw
our proposals, no matter whether the changes are applied now or
continue to be worked on in bugs.


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.

Discussion is more productive than trying to force things. In the end,
what Ian says doesn't matter - what the browsers implement does. Eric
is supportive of this and IIRC so is Frank. That's the progress you
want - not stopping a solution for multitrack from going in because
not all the details have been sorted out yet.

I don't mean to force anything and maybe I am mis-understanding the HTML WG process (which is anything but simple), but I think we should avoid the situation where the multi-track solution goes out for LC with a significant requirement not addressed (and btw, this requirement has been there from the beginning and is properly addressed in Change Proposals 2 & 3).

My opinion is that if we shipped the spec to LC with a multi-track solution that didn't meet the track discoverability requirements, this is evidence that despite our best efforts we weren't able to converge on a solution in time. It would be better to leave it out and work on it during Last Call. Remember that we were all skeptical that we could get this done in time, but we agreed to try.

The other four issues all have work-arounds, but the kind issue does not.

What's important is to me whether there's a general consensus. If the people with opinions on this say it's no big deal and they're reasonably confident we can work it out as a bug, then fine. But last I heard this was not the case as there was a difference in principle as to whether W3C should define these "kind" values itself for audio and video.

...Mark


Cheers,
Silvia.

...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

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