RE: Requesting Spec Text Additions

Eric Carlson wrote:
>  
> On Sep 24, 2010, at 3:25 AM, Martin Kliehm wrote:
> >
> > I would prefer that the Media sub-team redrafts it,
> >
> 
>   I would strongly prefer that the media sub-team *NOT* redraft it
> because the current text doesn't need much revision, and because it
> will take substantially longer than it will take the editor (we don't
> have experience with the tool chain, are likely to produce something
> that requires further work to match the spec language, etc, etc).

FWIW, this has already been discussed within the sub-team, and we are
generally all in agreement: there is much good meat on the current spec
text at WHATWG, with the largest concern that it references a specific
Time Text format at this time (WebSRT). It is worth noting as well that
what is in the WHATWG document builds upon work that originated at the
W3C, work that was set aside while we finalized the User Requirements
document, so that we had a complete matrix to assess solutions against.

We are asking at this time that the text be reworked by the editor to make
it agnostic in regard to specific text formats, but this is but one part
of the larger proposal. Generally the work regarding the <track> element,
the JavaScript API (etc.) appears to be non-controversial to us. However,
getting that text into the W3C Draft allows for further examination within
the larger group at the WS3C, at which point if there are concerns bugs
can be filled, etc.  It is through the bug tracking process BTW that any
're-drafting' will take place, as we collectively refine and improve on
what has been produced to date.


> 
>   If the text inserted into the spec has problems, we will note them in
> the bug used to request this edit.

Exactly, but to do so, we need spec text to comment on, thus this
request/move at this time. 


> 
> > because I believe they are less biased concerning technologies,
> >
> 
>   I very much doubt this, the sub-team has members with many different
> backgrounds. Some members are probably more biased about technologies
> (speaking personally), and some are *certainly* more biased about
> accessibility solutions.

LOL, yes, I am also part of the media sub-group, and I don't think it
would be a stretch to suggest that my bias is well known. With that said,
I believe this is the right move forward as well.


> 
> 
> > less tempted to spec yet another TT format,
> >
> 
>   We are asking to have two sections of the WhatWG spec moved as-is to
> the W3C spec, and one section moved after editing to make it technology
> neutral. Where is there room in this request to "spec yet another TT
> format"?
> 
>   How are snide comments helpful to this discussion?

I don't think Martin's comment was particularly snide, but rather simply
reflects an existing concern that many have. For those not closely
following the discussion, the work around creating user-requirements[1]
and reflecting technical impacts[2] will be used to assess time text
formats moving forward. Whether the baseline format will be WebSRT, TTML,
SMIL or a newly minted format is open for continued discussion at this
time: getting the <track> element and JavaScript API text (and related
bits) into the draft has little impact on those discussions.
[1 http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements] 
[2 http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Checklist] 


> 
> > and more likely to choose a solution that is fully accessible and has
> wide support in different browsers so that a maximum group of users
> will benefit.
> >
>   We aren't asking to have the editor "choose a solution". The WhatWG
> spec has the solution we believe is likely to be supported by browser
> vendors and benefit users. Have you read the spec section we are
> talking about?


Eric, there are some who have issue with WHATWG, and the autocratic
process they use, so they may not follow along closely to what they are
doing 'over there'. One reason why we are looking to move this text into
the W3C Draft at this time is so that those committed to the W3C consensus
process can review and comment on this part of the specification as well.
Martin, there is little-to-no downside to this suggestion at this time.

JF

Received on Friday, 24 September 2010 20:36:58 UTC