See also: IRC log
<trackbot> Date: 27 April 2011
<silvia> :)
<scribe> scribe: JF
<Sean> its telling me its not valid
JS: thinks we should have a
post-mortem on issue 152, what happened and where are we
now?
... believe we are still on track...
SP: the chairs decided what we were trying to do was not possible based on WG rules
everyone else pulled back their change proposals
so that ian's work moved forward uncontested
and now we even have some of the bugs resolved
JS: does anyone have anything to add to that?
JB: were we not at some point relying on ian's proposal?
JS: maybe that would be an introduction to where we are now?
EC: what happened was when we returned from F2F, ian had a CP. Based on email with many, he incorporated those changes into WHAT WG
based on feedback, he was updating running spec at WHAT WG, but not his original CP
thus his CP was out of date
so ian withdrew his CP, as did others, and so the WHAT WG text moved into the W3C spec, and John added the 5 bugs against the revised W3C spec text
JB: thanks for the overview - added clarrity
we need to be careful on watching where text is evolving
with a goal to avoid this confusion again
MW: was watching process, and wanted to be sure his concerns were included into one of the CP's
and what ended up was that was not what happened
conclusion - always have a valid Change proposal in hand
JB: this was unusual for w3C process
this was atypical
JS: many found this quite confusing
EC: to be fair, our problem was that we did not have a valid change proposal
JB: that may be part of the problem/issue, but that was not 100% clear - there was a missed understanding
the concensus process was lost
MW: the problem was there was no CP last Friday
SP: not unhappy with the process, we got what we needed, and the bugs are being pursued. In essence we got what we needed
EC: Agree with Silvia - in the end we resolved a contentious issue by amicable resolution
JS: generally good. So we now have those 5 bugs, some of which appear to be resolved. Do we expect this all to be resolved before LC?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12544
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12545
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12546
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12547
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12548
JB, can we get a status check
Bug 12544 - MEDIA CONTROLLER requires track kind for in-band tracks
SP: this has been applied
we now have a get @kind function in the spec
MW: there remains an outstanding question about what @kind values can be gotten back
how do we decide - not in concurrance with ian's perspective, woulod prefer that W3C define the list
should be independant of the container formats
so there should be a single place where these are define
JS: the fact that they are marked
resolved may not be sufficient for this group
... what can be retrieved is more important than how for
some
we should be looking to ensure that our concerns (user requirements) is fully met
EC: I sympathize with both perspectives. None of the existing container formats have support for most of these @kind values yet - they don't exist
defining them in W3C is an interesting thought exercise, but if they are never implemented it is simply a thought exercise
MW: is a chicken and eg problem - do we wait for all the media formats to define the same values with different meanings/names?
Seems a more productive way forward is to define a small number of values so that others can reference
+q
MW: if we put the stake in the ground, we show leadership
JS: sounds like there is more discussion on this issue
SP: let's continuing discussing - this is something basically new
happy to continue the dialog
Bug 12545 - MEDIA CONTROLLER requires loop attribute for grouped multitrack
SP: both Philip and ian are asking for the use-case, and Eric and Silvia are attempting to explain
both ian and Philip believe there is another way forward, but silvia believes is a dangerous way forward
but is not a deal-breaker. would like things to be consistent, but not a do or die issue
Bug 12546 - MEDIA CONTROLLER requires autoplay attribute for grouped multitrack
SP: ian is also asking for a use-case
discussion is happening, but this is not quite clear yet
perhpas the first implementation will help resolve this as well
doesn't believe this is a blocker, nor a fundemental a11y issue
EC: disagree that it is not a a11y issue
we *do* need to discuss this more, but email discussion to date is that Eric was unclear on one aspect of the media controller API
believed that if 1 played, all played, so this might change things in the discussion
JB: also believes that this is important for a11y
SP: maybe we need to put the a11y keyword to this bugs
Bug 12547 - MEDIA CONTROLLER requires readyState for grouped multitrack
SP: is a disucssion tath Eric should summeraize
EC: if we don't have it then a script has no way of determining a ready state
eg; if you have a js controller that is attached after the group is created, then there is no way of knowing what the state is
JS: sounds like it needs additional work
Bug 12548 - MEDIA CONTROLLER requires onended event
SP: believe this has been added
JS: so our change for 12548 has been accepted?
JF: status still reads new
JS: we should verify
<silvia> HTML5 spec has:
<silvia> A http://dev.w3.org/html5/spec/video.html#mediacontroller has a most recently reported readiness state, which is a number from 0 to 4 derived from the numbers used for the http://dev.w3.org/html5/spec/video.html#media-element readyStateattribute, and a most recently reported playback state, which is either playing, waiting, or ended.
http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0307.html
EEC: I think there may be an issue with the script thta pushes the SVN text from one location to the other
JS: considering the other 4, where do we start?
suspect mark would like to go back to the @kind discussion
<silvia> http://dev.w3.org/html5/spec/video.html#dom-tracklist-getkind
EC: also have a proposal on how
to handle that issue
... it is useful for us to come up with a list of the @kind
values, but we need to go further and ensure that those @kinds
are added to the container formats
silvia can do this for OGG, David Singer can likely do for MP4
this is likely the right way forward
MW: this would be great
if we write down a list then 3gpp and mpeg will reference that list as well
SP: Ogg already has a list
ian based upon what OGG already had defined, but understand that MPEG has some definitions from DASH
<silvia> http://wiki.xiph.org/SkeletonHeaders#Role <- ogg's list
but 3gpp is waiting on W3C
SP: full list from OGG
but may not have everything that 3gpp are expecting
EC: seems that these groups are
all waiting to hear what we propose
... we should add a section to the reference documents
MW: is this a normative document?
JB: not sure
seems this should be a normative reference from elsewhere, not internal to HTML5
JB: a PFWG might be the place to do this - would need a minor charter mod for that
SP: we should agree/assure that this can be modified in the future
+Q
since it is just a string
might see new values emerge over time
wouldn't want to see a fintie list
MW: for clarification - in external discussions 3gpp and MPEG DASH are not interested in defining these values
they are waiting for W3C to define the URN for the track kinds
just like has already been done for text @kinds - why is this any different?
SP: from OGG's container format, they are all the same
EC: seems that having the definition in the HTML spec is a bit backwards - these are not specific to html
MW: not specific to media container formats as well
EC: my point exactly
SH: We can create a wiki like the microformats did
JB: another approach would be to define a collection of these and post them at W3C.
SH: wanted to make the point that whether wikis are an issue or not, the chairs have already made the decision that the spec can reference wikis
so if it is a problem for our list, then it would be a problem for other lists as well
MW: this is not specific to html, even less for container formats
however anyone writing html will want to know what these values are
so there is an html need to define this
EC: don't disagree that the spec needs to define the labels, but the list and definitions need to come from somewher else
JS: do we agree that a canonical list needs to be defined, and that W3c is the place that this should happen?
(appears there is no disagreement)
Is there also consensus that the html5 spec is not the right place for this document?
SP: not necessary a good approach
this should be in one place
+q
SP: what html does is places a normative list in the spec
but other groups would need to replicate this list
but they shouldn't be restricted by an html list
JF: disagrees with Silvia's proposal - should be in one location so that all ca nreferrence one document
JB: this might take too long for HTML5's timeline
SP: doesn't fundmentally disagree with JF, but container formats may need more than HTML5 requires
JS:
on the list of what a container can do, we can suggest that this list is a set of know values that container should support
but we should not lock it down
however if there are new requirments, there are W3c processes for adding to canonical requirements
JS: comment 2 - why not let w3C figure out where and how to register these values. Our groups purpose could be to come up with an initial list, and not worry exactly where to house that list
MW: nobody is suggesting that container formats be constrained by this
MPEG has defined a flexible method for defining an URN for specific set of values
there appears to be a small set of use-case now
that could be used in multiple use-case
JS: so, are we in agreement that a) W3C should define the canonical list, b) that W3C figure out where this would happen and live?
<mark> http://www.w3.org/WAI/PF/HTML/wiki/Track_Kinds
JB: how much of this specifically is related to a11y and not a larger container format issue? If it is primarily for a11y use then it may change the quesstion
JS: there seems to be a fair bit of a11y and i18n issues
EC: there *Is* a need for a list of a11y terms
and it should be in a document that comes from thta group. but in HTML5 the labels can apply to those terms. in the container format, it is those terms that get mapped to the container formats
so the canonical definition should be what a11y NEEDS
JB: so this makes it appear that this is PF territory
SP: looking at mark's list, there are 2 or 3 that would make sense to add
supplementary, commentary, and clear audio
SP; as eric suggests, we should focus on the a11y reqs here. David singer also had some suggestions
MW: to add one to that list, there are situations where the only place to get captions is when they are burned into the video itself
so it would be nice to be able to label the video with captions/subtitles there
SP: would that actually be supplied as a seperate track in the resource, or is it simply a description of what is already burned into the video file
is @kind then the correct way to define/describe this/
MW: what we have today is some instances with caption burned into the video
JS: this is going to exist for smoe time due to legacy content
MW: if we can extract that in any way, then we would extract the text and store it seperately
or offer 2 versions of video, one with burned in, one without (Mark is this correct?)
SP: agree, to offer this to the end user as an undefined alternative
MW: there is a usecase for machine understandable extraction however
for example, always show captions
EC: agree 100% - the right thing is that to have an @kind that says there are captions
if it is applied to an audio track, then it is an error, but if it is included then it is up to the user-agents to intelligently do something with this
so a new label for 'captions' for burned in captions
MW: there appears to already be some duplication from different groups. if everyone agrees we can narrow down to one term and common definitions
SP: suggestion - make 2 tables: one like you have, and then a second that contains the ones we have agreed to
MW: OK, agrees to that
... do we assume that the initial five values have
agreement?
JB: in the status section, in addition to reflecting what is in the page, might be useful to also show who is involved in the current discussion
JS: 2 questions - we are looking here only at binary formats? is this correct?
(yes)
<mark> I added "This page is a work-in-progress and is being actively studied by the HTML a11y working group"
we were trying to be very careful of terms - so it should be audio description, not video description
SP: 'description' is in the spec.
JS: there is some confusion, and in the user reqs we took pains to delineate the difference between binary descriptions and text descriptions
as long as the taxonomy is clear and precise
JF: is description for both audio and text be a problem?
MW: we need to define needs and then word terms
as I undertand in the spec, there is a list of names, but with no definition
JS: we do need to do that, to define the terms. this is why we were very careful with the usage of names
SP: it is the mime type that does the definition
so the generic term of description makes more sense, as it is the @type that defines the type of @kind resource
SJ: go around the table for the values to take consensus
so on initial five: alternative, description, main, sign, translation - are there any concerns here?
JF: are there any disagreements that those 5 values required for a11y
JS: there was some discussion earlier about defining "main" versus "primary"
JF: propose we continue on this discussion on the mailing list
JS: do we want to continue with 2 calls a week?
(we will remain with once-weekly calls)
JS: are there any other
hightlihgs on the reamins bugs that we should be discussin
today?
... thanks for the good work - it appears we are actually in a
good way despite last weeks confusion
next call is next wednesday
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/SF/SP/ Succeeded: s/JSD/JS/ Succeeded: s/DSAH/DASH/ Found Scribe: JF Inferring ScribeNick: JF Default Present: John_Foliot, Janina, silvia, mark, Judy, Frank, +54558aaaa, Sean, Eric_Carlson Present: John_Foliot Janina silvia mark Judy Frank +54558aaaa Sean Eric_Carlson WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 27 Apr 2011 Guessing minutes URL: http://www.w3.org/2011/04/27-html-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]