<gitbot> 01[13html01] 15rubys pushed 2 new commits to 06feature/whatwg: 02https://github.com/w3c/html/compare/5069600eb2e9...a9ffe895f193
<gitbot> 13html/06feature/whatwg 145eb5e2b 15ianh: [e] (0) Clarify what we mean by 'poster frame' of an animation....
<gitbot> 13html/06feature/whatwg 14a9ffe89 15ianh: [e] (0) Be clearer about how preparsing handles running out of bytes....
<darobin> MikeSmith: you're around man?
<MikeSmith> darobin: here now
<MikeSmith> at Denny's near my hotel
trackbot, start meeting
<trackbot> Date: 23 April 2013
<scribe> scribe: Josh_Soref
<scribe> scribenick: timeless
[ Everyone introduced themselves ]
paulc: we'll start with an
Unconference
... ruby has this page open with the schedule
... there are requests from the Media TF
... for a session on EME
... - current bugs
... - Accessibility TF wants to talk w/ them about alternate
media in the clear
... I'm proposing to do these after lunch
... and i'm proposing to do MSE first
... it should take 30 minutes?
... eric(?)
... i'm assuming lunch is 12p-1
... we'll do MSE 1p-2
... then EME after that for 90 mins
... there are a fair number of open topics there
... a larger section on Candidate REC status
... - update on testsuite, coverage, status
... krisk wanted to talk about github and branching
... i suggested working on figuring out which parts of the
document are passing exit criteria
... and talking about Features AT RISK
... MicroData met yesterday
... i suggested to darobin that this is a fairly large
topic
... that we start it this morning
... we'll finish this section w/in half an hour
... and then the rest of the morning to start on [hand-pointed]
topic
... the WG has 2 docs out to CR and our job is to get them
past
... ruby: can you put CR status for 9:30a-10:15
... and part 2, 10:30a-12noon
... that covers the big things
... for this morning and early this afternoon
... Moving the polyglot spec forward
... eliot?
eliot: i want to hear where
people's feelings are
... it could be 10mins or 45mins
<CyrilRa> Anyone on phone bridge? Been on bridge from Agenda for a while (and on IRC Channel), on my own…
paulc: ruby, open a slot tomorrow
morning at 9am
... darobin heartbeat, can i lump that w/ misc for tomorrow
morning
darobin: sure
paulc: we want to talk about
various documents
... and we want at least oral concurrence
<krisk> krisk: F2F wiki http://www.w3.org/wiki/HTML/wg/2013-04-Agenda
<eliot> hober
hober: did we schedule EME?
<CyrilRa> Update agenda to reflect IRC Channel
paulc: yes
... assigning transcript to audio/video
... Accessibility TF wanted this
... JF_, do you have any idea how long it will take?
JF_: 30mins? maybe longer
paulc: ruby, put in post coffee
tomorrow morning
... Web Perf issues re:HTML5
... put after coffee in misc 2
... session on wiki "Extension Spec Status"
... Moving Image Description aka Longdesc
... - it has a FPWD, and the TF intends to take it to LC
... chaals ?
chaals: at least 3 minutes
paulc: put it in misc 2
janina: some of us won't be here then
paulc: ok, ruby,, create a slot
today @ 11:45a
... i think that covers everything on the list
... anyone have anything else?
... darobin, looks like we have time for another testing slot
tomorrow
darobin: if we need it
paulc: this group needs to figure
out how to use the time
... we need to figure out which parts need testing, and which
don't
... if we need to drive through the spec section by section,
that's what we'll do
... call that "candidate testing part 2" tomorrow
afternoon
... other topics?
<scribe> ... "New features for html 5.1?"
plh: can we have a slot for HTML WG Charter?
paulc: how much time?
plh: 30mins
paulc: any other topics?
plh: paulc, wanted Charter tomorrow
paulc: ok
paulc: * HTML Test Suite
coverage, gaps and status
... * Usage of Github and branching (Kris)
... * Review of which parts of HTML5 pass the "passive exit
criteria"
... * Status of HTML 5.1 and Canvas open bugs
... * Status of Features at Risk (more, less?)
... * Getting Microdata to CR (Editorial team)
paulc: i think we can do
Microdata first
... does an editor want to speak?
... in December when we took HTML5 and Canvas to CR
... we had an Objection in taking Microdata to CR
... which is why it didn't go out at the same time
... we talked about this as chairs and editors
... i think we need a further update
MikeSmith: we're even further
blocked than before
... we'll have fewer implementations potentially than when we
spoke a few months ago
... the Google Blink team decided to yank the implementation of
the Microdata DOM API
... it's likely to disappear from WebKit also
... the Microdata specification defines some attributes that
are extensions to the HTML language
... we don't have implementation conformance requirements
... we only have conformance requirements for validators
... the one thing we have is this DOM API
... we have 2
... we had one in Opera
... my understanding is Opera is End-Of-Lifing their web engine
(Presto)
... and they'll be shipping WebKit/Chromium
... I don't think we can count the Opera engine
... we have one implementation in Mozilla (Gecko)
... unfortunately
... in discussing w/ the Chrome team
... they're not just yanking the implementation
... they're not interested in implementing the specification as
spec'd
... we could work to go to CR
... but, six months from now, we're unlikely to be able to
exit
... also, editorally
... there's no industry momentum behind Microdata
... it was nice at the time
... it lit a fire under the RDFa to force them to make their
API fit to market
... it pushed the RDFa partisans to align w/ what we asked them
to do
... now that it's done
... I don't think the entire world needs to work on two
different
... Practically speaking, Schema.org started w/ Microdata
... but now RDFa has a lite version, which is quite usable
<darobin> [despite its terrible name]
MikeSmith: I don't think orgs
like Schema.org which are using embedded metadata
... want to do things twice
... I don't think the investment is necessarily needed to
continue
... I, myself, don't think it makes sense to continue to pursue
this
chaals: I put myself on the queue
to call Bollocks
... 1. Microdata is in large part not directed at
browsers
... it's the least interesting application in many cases
... browser implementations aren't always the implementations
you're looking for
... in some things we do in HTML
... we couldn't care less if it's used in the browser
... things like Authoring systems
... for Microdata, it's for Data management systems
... you might lose Browser implementations
... Yandex has a Microdata implementation for schema.org
... and we can see interoperable
<CyrilRa> Any update on phone bridge?
chaals: we don't really care if
it's implemented in a browser
... we want to see if it's really implementable
... the approach for "what is a valid implementation
requirement"
... should be opened up a bit
... there are boatloads of Microdata in Russia
... we use Microdata in Yandex, which we implemented
early
... so there's a lot of it
... we lead the Russian market
... as Google leads the US market
... i'm not necessarily disagreeing w/ MikeSmith 's
conclusion
... but i'm disagreeing your steps
<Zakim> MikeSmith, you wanted to thank Chaals for volunteering to serve as the W3C editor for the Microdata CR spec
MikeSmith: if you are invested in
it
... then you're welcome to edit
rubys: i want people to focus on
actual recommendations
... MikeSmith was talking about Terminating as a NOTE
... and that was what i heard
... but from chaals, you said we don't care about the html
bit?
... but we want the rest?
chaals: i was trying to avoid committing to find an editor
rubys: if we don't have an editor, we should terminate
chaals: we should do things for
reasons that make sense
... if we don't have an editor, no one cares about it, we walk
away
paulc: when chairs did a call for
editors last summer
... we had a lot of answers, but they had limited
experience
... and we turned them down
... don't assume the only possible editors are in the
room
... people might not have a primary interest in Microdata
... but they might volunteer to get editing experience
... the right way forward is for chairs to do a call for
volunteers
MikeSmith: yes
... if a WG, esp a high profile WG like this
... puts out a call for editors
... we'll have a lot of people who will step up and say
"yes"
... "oh, btw, what is Microdata?"
... we don't want people who don't know what it is to step
up
... they won't stick around
... abundance of potential editors isn't a solution
rubys: you suggested the APIs are
AT RISK
... we could take some decision on the APIs
... you were suggesting is that the parts that chaals spoke
to
... search engines, processing systems
... are the attributes
... and we could propose to move them somewhere else?
... when we went to CR
... we had a missing section
... we spoke about moving it to the HTML base spec
paulc: i don't think people in
the room understand what happened at the Director's TR Call for
Microdata
... I want to refresh people's minds
MikeSmith: i'm trying to remember
that call
... if someone else on the call?
darobin: we had a Director's Call
to move Microdata to CR
... during the call, we noticed a section had gone AWOL
... there was a merge error from the WHAT WG spec
... the call failed, because we couldn't ship a spec missing an
entire section
... after which the Blink announcement happened
rubys: three things
... 1. API
... - no one in room has interest
... 2. Definition of Microdata
... - Yandex is interested, but not necessarily to find an
editor
chaals: if you want the spec in Russian...
rubys: 3. Microdata in HTML
... which is currently in the HTML spec
... it should probably be tombstoned
... if decision is to make it a FINAL NOTE
... it should probably be moved back
paulc: why wouldn't we fix the
missing section
... and go to CR w/ the API marked at risk
rubys: if there's interest and an
editor
... that makes sense
paulc: trying to make sense w/o worrying on editor
darobin: i don't think we should
focus on finding an editor
... i don't think it's a lot of editorial work
... tombstoning, dropping API, etc, all are short
... if there's strong interest from Yandex
... we can probably take to CR w/o the API
... if you want us to take it
... show us another company w/ interest
MikeSmith: we made a decision a
long time ago to split the Microdata stuff out of the HTML
spec
... the upstream spec is continugous
... we could put it back there/leave it there
... part of why we pulled it out was political
... to show we didn't want to give it an unfair advantage over
RDFa
... we could put it into HTML.next
paulc: that's another
... alternative
... 1. go to CR w/ part of spec AT RISK
... 2. archive w/ WG NOTE
... 3. fold the attributes in HTML for 5.1 - as Yandex, and
schema.org use them
MikeSmith: 3 is what i'd
suggest
... let's reduce the amount of extra work for myself
darobin: not just you
paulc: darobin, how much work is it to integrate back into HTML5.1?
darobin: even less than the others
<Zakim> MikeSmith, you wanted to say that another possibility is that we just put Microdata back into the spec where it started from
rubys: MikeSmith, what do you propose to do w/ the API?
MikeSmith: leave it there for now
paulc: anyone in the room want to
express an opinion on the three options?
... 1. go to CR w/ part of spec AT RISK
<darobin> [we could even come up with a better API that also covers RDFa]
paulc: 2. archive w/ WG
NOTE
... 3. fold the attributes in HTML for 5.1
chaals: we'd like it to go to CR, so it isn't spinning around
hober: i agree w/ MikeSmith, roll it into 5.1
paulc: other opinions?
Mark_Vickers: confused
... MikeSmith spoke about this
... can we get multiple implementations
... is everyone turning away from this?
... option 3, doesn't that cause more risk?
... to the 5.1 spec
... not getting multiple implementations?
... not getting things people want?
... and it seems to contradict the extensions spec model
darobin: i understand your
confusion
... putting it in 5.1
... a. it's less work for us
... b. it gives us more time, 5.1 target is 2016
... it doesn't push us to make a decision in the next six
months
... give people a chance to use it, or give us a chance to
notice it's completely dead
... c. re: relationship to extension specs
... it interacts w/ lots of other sections
... it interacts w/ syntax, drag and drop, etc.
... it's difficult to extract
paulc: other
questions/comments?
... chairs will take an action item for a proposal
... need to figure out if we want to do a CfC or something
else, I expect to hear an objection if we do a CfC
chaals: i doubt Yandex will raise
an Objection
... unless we offer to pony up resources
... this isn't a hill we'll die on
... strong objection path is unlikely
paulc: what if we move the
attributes to 5.0?
... the reason this is in microdata5.0
... was because the WG made a decision to split out the
content
... it's the attributes you're most interested in,
right?
<rubys> ACTION: sam to bring microdata proposals to the working group 1) terminate as a note, 2) take attributes to CR, 3) move to 5.1 [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action01]
<trackbot> Created ACTION-225 - Bring microdata proposals to the working group 1) terminate as a note, 2) take attributes to CR, 3) move to 5.1 [on Sam Ruby - due 2013-04-30].
chaals: yes
paulc: why can't we just fold this back into 5.0?
chaals: same political reasons as why we split it out
MikeSmith: if we put the
attributes back into the spec, it won't affect progress of the
spec
... we don't have conformance requirements
paulc: right, that's why i
asked
... but chaals, i think you're right, we'd get an Objection
[ Time check ]
darobin: i suppose most of you
are familiar w/ W3 process
... one of the things you need to go from CR to PR
... is a Test Suite
... to prove that the nice piece of prose is supported by
implementations
... when you have a spec as large as HTML
... writing a Test Suite is a big task
... we put a lot of effort into it
... we did an extra push
... to ensure we have a good Test Suite, so we can exit CR on
schedule
... a few testing topics that I want to introduce
... the testing repository has moved to github
<plh> zaki, this is html_cg
<krisk> https://github.com/w3c/web-platform-tests
darobin: we have a relatively new
repo on github
... in addition to HTML tests
... this is the repo for all w3 related technologies from
W3C
... possibly also for Khronos
... there's 2d canvas
... webapps tests
... an html directory - the html test suite
... in github fashion
... if you want to contribute
... you fork the repo
... clone it locally
... make changes
... push changes back
... make pull request
... someone working on test review team
... will give feedback or merge in
... we have a fairly straightforward workflow
... we had a test suite
... we noticed the bottleneck was in reviewing tests
... people would write them, submit them
... but they'd get stuck there
... if you're interested in helping review tests
... writing tests is difficult if you're not familiar w/ the
process
... but reviewing them is a good way to start
... we have w3c-test.org
... it has a web platform test subdirectory
... for HTML, see we have a breakdown
JF_: where is the Accessibility section?
darobin: this is html
... w3c has a fellow on loan from Facebook
... tobie
<chaals> Web Platform Tests
darobin: and they're working on
figuring out how to make the accessibility testing side
work
... accessibility testing is harder to make automatable
... they're considering Web Driver
JF_: there's a community of
driven people
... we could put Brawn instead
darobin: we're in the process of
raising funds
... and trying to develop tools, to do test running, result
gathering, analysis, etc.
... for manual tests, we have a prototype, we're not happy w/
it
... i wouldn't want to launch a big crowd sourcing on it
now
... they'd give up on it within a day
... for CSS, there are plenty of things you can't
automate
... we want to push a crowd-sourcing effort
... no timeline for that
... plh ?
plh: we're going to develop the
infrastructure
... i don't think we'll be in a position to push for
crowd-sourcing w/in 6 months
... and it's hard to align with a timeline
... i can't rely on crowd-sourcing if i need to deliver by
2014
darobin: you were talking about
crowd-sourcing writing of tests
... but JF_ was talking about crowd-sourcing running
JF_: we have a strong community,
both professional and volunteer
... who'd be able to run tests
plh: for long term, we'd like to
rely on Driver
... i don't think we'll rely on it before next year
darobin: Accessibility testing is definitely part of it
plh: when we test <track> or [Media].mediagroup, it would be part of that
darobin: to give you a sense of
the size of the Test Suite
... we have over 10,000 tests
<chaals> [/me wonders about webdriver running accessibility tools that are not built into browsers - but not sure that's a critical thing to say here]
darobin: we want 26,000
paulc: from my point of view,
this is going at it ass-backwards
... HTML5 WG went into CR w/ a passive exit criteria
... that we don't need to test things if we claim we have
interop
... we have a grant to not to write tests
... i understand there's a wide desire to have a broad test
suite for the platform
... our job in this WG is to get out of CR
... if we believe we have compat in an area, then we don't need
tests there
... this is creating a higher mountain than we have to
climb
darobin: there are 2 things
... `the test suite we need to exit criteria`
paulc: no
... we need test results
... you don't need a test suite to get out of CR
... you need interop proof that the director will accept
... this WG went into CR w/ another way to do that as
well
... "if we can identify parts of the spec that are broadly
implemented
... by implementations out there
... then we don't need a test suite for that"
darobin: we would need 8.5 years
to finish this
... i don't think our goal is to exit CR in 2021
... which is why, within the context of exiting CR for the HTML
WG
... there's a subset we need to target
... we don't need 100% in all these boxes
... it's important to have syntax, and some other things
... but we need to prioritize
... figure out which areas we feel definitely need a test suite
to demonstrate interoperability
... i don't think we can go to the Directory and say we don't
have any tests
... this group needs to decide as a group which to work
on
... we have 6000 tests waiting for review
... testing for Video, Track, things we know are new
mjs: it makes sense to prioritize
the tests
... stating the criteria as the new features that need
tests
... isn't the right reason
... <video> is possibly not what we need tests for
... we have lots of real world consumers
... whereas microdata has less use, or older elements
... even though they've been around forever
... e.g. if they were loosely defined before and are now
strongly defined
... we should ask "do we have some reason other than a test
suite to decide if something is strongly interoperable"
[ laughter re using microphone ]
krisk: master branch has WebGL
and other stuff
... really concerned we're losing focus
... there's a CR branch that hasn't had updates in month
... there's tons of action in master
... there's tons of tests in master branch for canvas, but they
don't work
... the tests in CR branch work
... in concerned about how this test suite which will last for
many years converges w/ our plan to get the spec to REC
darobin: i agree
... the html testing TF
... should focus on getting to REC
... contributing to the broader thing, but not getting lost in
it completely
... i wasn't aware the canvas test suite was broken
krisk: testing wants stuff to be
automated
... we made canvas automated w/ TestHarness.js
... but we're churning it
darobin: you should raise a bug
on that
... we are saving time by making them automatable
krisk: if we're just trying to say that <canvas> works and we're done
<CyrilRa> silence
MikeSmith: ms2ger made automation for <canvas> testing
<krisk> Here is an example http://www.w3c-test.org/web-platform-tests/master/2dcontext/path-objects/2d.path.arc.angle.5.html
[ paulc will carry mic around for the next half hour ]
<rubys> http://dev.w3.org/html5/decision-policy/public-permissive-exit-criteria.html
bryan: we should clarify focus on the spec
<krisk> This is in the master branch (doesn't work)
bryan: which section needs
tests
... that would help Bin (Hu) go through the spec
... to decide which parts need testing
... there's a need to get down to the next level
<krisk> In the CR it's working http://www.w3c-test.org/web-platform-tests/CR/canvas2d/path-objects/2d.path.arc.angle.5.html
bryan: we'd like to focus the
test writing
... which parts we should be writing tests
... which sections will have this `informal exit criteria`
[ paulc projects http://dev.w3.org/html5/decision-policy/public-permissive-exit-criteria.html ]
paulc: this is the exit criteria
"For features that are well known to be widely implemented and deployed, and where implementations are believed to match the specification, the Working Group will assume effective real-world interoperability without testing."
paulc: i want this WG to start
identifying those sections
... instead of building a massive infrastructure for html5
<CyrilRa> mic
paulc: that will identify which
in that bar graph need testing
... i was reading the text from the judgement level
... i'd like us to spend some time at this meeting
<chaals> [+1]
paulc: w/ the ToC of HTML5 and
Canvas
... Accessibility
... mjs, i'll pile on on Video
... but someone will put up a hand "in section .2 there's this
feature i tried the other day"
... ah, ok, now we're getting the exception list
... to tell the testing people "we need a test there"
... i don't care what they do
... but we need the interoperability results
... "here's a test, MS, you don't do this the same way as
Google
... we need to figure out if the spec is wrong, if you're
wrong, if they're wrong
... of if something else is wrong"
... i agree w/ darobin, we won't get to the humongous test
suite in time
... w/ the task ahead of us
darobin: we [w3] will get to the
humongous pile, but not this group
... there's another group that wants to do that, but not this
group
... the two are related, which is why i wanted to present the
context
tantek: Tantek Celik, Mozilla
<plh> --> http://www.w3.org/2013/04/test_plan2.html W3C open Web Platform testing plan
tantek: there were large parts of
CSS we thought were widely deployed and interop
... e.g. Margin collapsing
... in CSS1
... while developing the test suite for CSS2.1
... we thought things were widely implemented and
deployed
... unless you think browsers are better implemented than
CSS
... i'd challenge the assertion than the belief
krisk: thanks mjs (for
yielding)
... back to darobin 's report
... going from the spec, section by section
... some are "this is just a definition"
darobin: this has been updated since the first version
krisk: in "infrastructure", there
are a bunch of definitions
... a good thing to recognize
mjs: the point i'd like to make
is that
... as the w3 process is set up
... getting to the REC stage
... the final stage of the process
... has a couple of different purposes, w/ different
goals
... 1. is test suite driven and interoperable
... 2. is to prove that a specification is truly ready and
should be referenced
... 3. is the w3c patent policy starts applying
... until that point, the policy is at best informal
... this leads to a tension
... between wanting interop
... and wanting the patent policy and getting people to "use
this thing"
... part of the reason for the informal interop bit
... is to allow for the second to parts
... i don't want to downplay making a comprehensive test
suite
... but it does make sense to prioritize portions for the test
suite
... even though i agree on roughly interoperable bits
... there are bits that are slightly complicated
... saying "html5 is so much better than html4" is worth
doing
... and not waiting too long
paulc: darobin, if this WG could identify areas that need testing, that would be useful
darobin: yes
<bryan> +1
paulc: and areas where this group
doesn't think need testing
... that would be useful
... and work to identify qualitatively, interoperable,
independent, implementations and judgement level
chaals: what mjs said, we think
it's important to ship this spec
... we expect we'll find more bugs
... we will want to improve stuff
<plh> --> http://www.w3.org/2013/04/test_plan2.html W3C open Web Platform testing plan
plh: the test goal of this WG is
different than the other test group
... a point i made to the testing team
... is that the HTML WG testing group will go for the
minimum
... the goals are different
... even if the goal of the testing project is valuable
... to push HTML5 to CR
... i pasted a link by tobie for what we think for the testing
project
... it's what we sent to our ...
... people are welcome to provide feedback
... this is wider than the scope of the HTML WG
Travis: the chart is good
... now we're trying to transition to defining what the WG
needs to do for testing
... i'd like to focus the quantitative bits on our goals
paulc: this topic isn't
over
... i'd like us to seriously consider using the time we have
tomorrow
... to use qualitative judgement
... not sure if we should do it as the group as a whole, or
crowd-sourcing (breaking up into smaller groups)
... you should expect we'll spend some time tomorrow
... i'll return to the agenda
paulc: did you make your point?
krisk: the effort gone
... into setting this up in github, could go on forever
... is that where the CR branch come into play?
darobin: yes
krisk: so all changes there?
darobin: no
... github repo has 2 branches
... 1. master - where everything goes first
... 2. cr branch
... - designed as a subbranch
... people interested in maintaining cr cherrypick
paulc: does that apply to Canvas and others?
darobin: yes
krisk: also for webapps?
darobin: idea was webapps would
do the same thing
... but not our problem at all
krisk: for a day or two
chaals: we're following the html
wg down the github rabbit hole
... w3 signed up for a decade long project
... w/ github
... you're committed to making sure it stays alive?
darobin: we're committed
krisk: the master branch
... e.g. for canvas
... wanting to avoid unnecessary churn
paulc: who is the person responsible for the cr branch in github?
darobin: probably me
paulc: you, or the testing tf, or ?
krisk: anyone part of w3 w/ pull privs can
darobin: so far we've been
working on the assumption that anyone willing to do work was
welcome to do the work
... i was working on CR, but i haven't in a while
... but we don't have someone specifically responsible
krisk: the TF could
... changes at TPAC, and moving to github
... html needs to move forward
paulc: what about test
results?
... if i'm an indivual
... or a company
... and trying to decide if i want to use the tests
... what's the setup to using the tests?
darobin: if you go to
w3c-test.org/web-platform-tests/ there's a way to run the test
suite
... you can check out the test suite
... we'd like implementors to use the test suite directly in
their CI systems
krisk: it's in github, but it's synced to w3c-test.org
paulc: so i load this, and click this, and click this
krisk: and you click a .html
file
... "you passed!"
darobin: it's missing
straightforward navigation
... great browser, it supports document.title
paulc: on criteria in exit
criteria
... the exit criteria testing requirements need to be publicly
available
... w/o that, crowd-sourcing wouldn't be possible
<chaals> q
paulc: i've been in groups where
the interop requirements were confidential
... krisk any points on github/branching?
krisk: action to make sure that
it's clear
... what's to do
paulc: action on Testing TF to make organization of github test suite is documented and clear?
krisk: correct
<rubys> action on krisk make sure that the organizational structure of github test suite is well documented
<trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.
paulc: let's skip: Review of which parts of HTML5 pass the "passive exit criteria"
<rubys> ACTION: krisk to make sure that the organizational structure of github test suite is well documented [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action02]
<trackbot> Error finding 'krisk'. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.
<rubys> http://intertwingly.net/tmp/wgtrends.cgi
<rubys> http://intertwingly.net/tmp/wgstatus.html
<Zakim> chaals, you wanted to raise the question of testing beyond the browser implementations
chaals: there's testing for
browsers
... but browsers are not the web
... there's one of the pieces of the web
... people need to create stuff
... i don't see that all in the plan
... that seems like a failure
... quite happy w/ "testing of can you do this is
anecdotal"
... saying "browsers will implement this code as
specified"
... without saying "people will produce it as specified"
... is a problem
paulc: how would we tackle this
problem?
... if you made this point when we were discussing our exit
criteria
... would we have changed them?
chaals: i did raise it then
[ laughter ]
<rubys> ACTION: on Kris Krueger to make sure that the organizational structure of github test suite is well documented [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action03]
<trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.
chaals: it's about also looking
at authoring systems and usage workflows
... everything has been done
<rubys> ACTION: Kris Krueger to make sure that the organizational structure of github test suite is well documented [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action04]
<trackbot> Created ACTION-226 - Krueger to make sure that the organizational structure of github test suite is well documented [on Kris Krueger - due 2013-04-30].
chaals: i'll type a comment
<chaals> chaals: We have a lot of testing oriented toward browsers. But (like accessibility testing that goes beyond "simple" browsers) we haven't talked about other parts of the infrastructure - processing systems, authoring systems, content management and maintenance tools. If these don't produce what is in the spec, it doesn't matter what browsers do since they won't be processing that kind of content
<chaals> ... so I think it is important that we remember the rest of teh infrastructure in testing
<inserted> [The search engine and other processing implementations of microdata are an example of important but non-browser implementations, and on the other side so are code generators which actually create microdata e.g. for schema.org]
paulc: microdata fell steeply
darobin: looks steep, but it fell from 9 to 1
paulc: when we appointed the
editorial team last fall
... we had 480 bugs
... i think the editorial team quickly got rid of the
spam
... when people typed the home row
... down to 420
... and since then, we're down to less than half
... we still have a bunch of important bugs
... bugs that might impact HTML5 or Canvas CR
... not clear what the situation is
... we need a downward trend
... and editors need to understand how to balance editing and
fixing bugs
... darobin ?
darobin: thinking about
that
... want to go through the buglist and mark absolutely must be
fixed for CR
paulc: maybe it'd be useful if
you did that
... we could add another histogram of that
... to see our flight path of zero bugs to cr
<rubys> ACTION: robin to give us a clear indication as to which html5 bugs apply to CR due in one month [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action05]
<trackbot> Created ACTION-227 - Give us a clear indication as to which html5 bugs apply to CR due in one month [on Robin Berjon - due 2013-04-30].
paulc: let's do that, on darobin
on behalf of the editorial team
... and on the canvas editors?
cabanier: i think there are like 6
paulc: should be very easy
cabanier: i think they're all for
the next version
... there's one we're going to remove
... hit regions, that changes an example
paulc: darobin if we can get that in the next month
darobin: yeah yeah
paulc: also, based on the
editor's meeting
... it isn't appropriate for someone to file a bug and wait 6
months for a response from the editors
... someone needs to triage incoming bugs
... comments from editors?
paulc: suggested at last week's
WG meeting
... that we might look at Features AT RISK
... this is the status section from the html draft
... looking at this
<glenn_> <h2 class="no-num no-toc" id="status-of-this-document">Status of This document</h2>
paulc: there's a lot of history
here
... anyone have comments on these items?
... App Cache was added AT RISK because of talk of an App Cache
v2
... I believe from TPAC was that this would be done in
WebApps
... chairs had an offline discussion
... chaals, i don't think you got yourselves suitably
rechartered
<glenn_> http://www.w3.org/TR/html5/#status-of-this-document
chaals: we believe that work is
covered by our existing charter
... we'll check again
... if it isn't, we'll recharter
darobin: WebApps has a "get out of jail for free"
chaals: it isn't free
darobin: simply by notifying AC
chaals: a bit more complex than that
darobin: to take things that were worked on by HTML
chaals: it's an admin
discussion
... between chairs and w3 and AC
paulc: will you discuss AppCache v2 this week?
chaals: yes
paulc: what did we do about <hgroup>?
chaals: it got kicked out
paulc: anything else to take out
plh: or add to the list
paulc: not sure how to add to a CR at risk list
rubys: we seem to think that API for Microdata is at risk
darobin: it's in microdata
paulc: anyone know what the cite= / bug 18915 thing is?
mjs: spec has a requirement that
if you use cite= that the UA has to have a way to get to the
url
... great wishlist, but never implemented
chaals: implemented in rare places, but yeah
paulc: not seeing further actions
<Zakim> MikeSmith, you wanted to ask if we talked about style@scoped
MikeSmith: we have two style@scoped implementations
paulc: i'll ask darobin and the
editorial team
... we're talking about heartbeat documents for 5.1
... do the editors think it would make sense to publish a
heartbeat of the CR?
darobin: we could
... not sure if there would be extreme value in it
paulc: if we did a heartbeat,
then it would be useful to update the status
... to note that it's unlikely for the feature to be dropped
because we saw implementations
... what would cause us to do a heartbeat for the CR?
chaals: a handful of important
changes
... taking <hgroup> out of the spec
... @ Yandex, after they struggled through the badly written
English in Russian
... and then told them that it changed
paulc: we have dropping
<hgroup> and adding <main>
... anyone in the group who think that's enough to trigger a
heartbeat?
chaals: what's the cost of a heartbeat?
darobin: grumpy editors
tantek: question i'd ask
... is any features that were dropped or changed were
at-risk?
... if they were at-risk, then i'd see no problem w/ a
heartbeat
paulc: <hgroup> was at
risk
... but <main> was added
... we know we're going back to LC
... <main> is in 5.1,
... we're folding 5.0
... but we were going to publish a NOTE
... but plan 2014 permitted extensions to be folded in
glenn_: what do you mean
heartbeat of a CR?
... a new CR?
... experience in other WGs
... if you make a substantive change, you need a new CR,
doesn't mean going to LC
tantek: my preference is to issue
a new CR
... i don't think that's supported by the CR process
paulc: we've issued WDs saying they were updated versions of CRs in other WGs
chaals: i'm working on the
process document
... tantek, your point is noted
glenn_: changes Silvia has made for Text Track
paulc: were those changes in 5.0 or 5.1?
glenn_: one specific change was
made to 5.0
... most changes were in 5.1
... one of the changes was going to be backwards
incompatible
... so she made one change to 5.0
paulc: where / when was this
discussion?
... Silvia was trying to abstract out to the extension spec
<plh> one can udpate a CR
<plh> the Process allows that
paulc: the portion for captioning
Janina: longdesc is obsolete in
CR
... what's the status?
darobin: we have an open
bug
... i haven't removed yet
... but i will, it will happen
paulc: another change to CR?
darobin: yes
paulc: thank you janina
<glenn_> http://lists.w3.org/Archives/Public/public-html/2013Apr/0063.html
paulc: people said earlier, their bar would be different by kind
darobin: this is moving a had to be supported out of obsolete
paulc: isn't that what Silvia's proposal was as well?
darobin: possibly
<glenn_> glenn: see above link regarding possible change (or need to change) html5.0 re: WebVTT features
chaals: we have this spec
... the spec is HTML Community Description Extension
... we have FPWD
... we've described longdesc
... we have outstanding
... we expect to go to LC
janina: June 11
chaals: the thing according to
the timeline of the patent policy
... we expect 150 days after FPWD, that we'll be done
... the question of integration into HTML -something- is
open
... we haven't had nor sought agreement to integrate into
html
... we figured we'd think about that more
... when the spec is actually finished
... when we'd actually gotten all that
... when the thing is ready
... whatever version of HTML is in the timeline in the point of
process
paulc: re: what Janina brought
up
... do you need the change darobin pointed to when you go to
LC?
chaals: we don't need it
... but we'd like it to be made
... it isn't time critical
paulc: just wanted to understand if it's a hard linkage
janina: no
paulc: do you need help from the WG on the 11 bugs?
chaals: yes, i'm supposed to
close 9 on thursday
... the way the TF works
... we propose resolutions
... at meetings, w/ a week delay since not everyone goes to
meetings
... there are 2 bugs left
paulc: when you go to LC
... is that a CfC between PF and HTML WGs?
janina: I expect
chaals: yes
paulc: you're effectively giving
a Time Table to the WG and people who read our notes
... that approximately in June
... to see a CfC
... since the TF owns the spec and does the work
... the TF will propose a Draft LC WD
... that would go to PF and HTML WG for CfCs
... and it would be published jointly by the WGs as the
extension spec
... is that fair janina?
janina: yes
paulc: this is an example of Plan
2014 working
... when we first proposed this, a number of people were
nervous
... and suspicious
... this is an example of Plan 2014 at its best
... only thing better is if we actually fold it back in
chaals: from my perspective, so far so good
janina: +1
paulc: experience as chair, best thing to do is recess/adjourn early
rubys: lunch is out there
paulc: please gather before
1pm
... topic will be MSE
[ Lunch ]
<gitbot> 01[13html01] 15rubys pushed 1 new commit to 06feature/whatwg: 02https://github.com/w3c/html/commit/03feebf25072ba37ee7095da756a8641b920f51f
<gitbot> 13html/06feature/whatwg 1403feebf 15ianh: [giow] (0) ImageData objects now expose an explicit pixel density, enabling them to be converted to BitmapImage objects correctly....
<SteveF> MikeSmith: http://www.w3.org/wiki/HTML/W3C-WHATWG-Differences
<gitbot> 01[13html01] 15stevefaulkner pushed 2 new commits to 06master: 02https://github.com/w3c/html/compare/dab1a6912807...dd337bd21b90
<gitbot> 13html/06master 1418097b2 15steve faulkner: tweaked aria-valuetext translatable conditions
<gitbot> 13html/06master 14dd337bd 15steve faulkner: Merge branch 'master' of https://github.com/w3c/html
paulc: in HTML WG, we have a
Media TF that's working on MSE and EME
... at TPAC last fall, we spent probably 2 hours going over
individual bugs
... I humorously commented that Google was telling Netflix how
to build their service
... and Netflix was telling Google how to build their
browser
... I got feedback that we had made good progress
... we don't have that many bugs
... we had a couple of topics
... open bugs, and getting MSE to LC
<paulc> MSE bugs
paulc: based on what worked @TPAC
in Nov
... my principle is that we step through these bugs
... you tell us what you know about them
... tell me what to do
acolwell: Aaron Colwell, editor
of MSE
... bug 20760 - defining interface for quality metrics
... adrianba had a proposal
... this is a subset
... i'm not sure of current status
adrianba: we want to discuss
this
... Adrian Bateman, Microsoft
... we're getting close to agreement here
... couple of minor things
... reflected towards the end
... we proposed a method, rather than an attribute to make it
clear you'd get a new object each time
... it's possible that the application could remember the
timestamp for when it called the method
... but if there's latency, having the timestamp in the object
makes sense
... we want to make sure all the data is from the same
time
... not sure whether we think that just this data is
sufficient
... it's obviously less than what we originally proposed
... which we thought was a good small subset
... it seems we're heading toward consensus with this limited
subset
... if there are problems w/ implementation experience, we can
change
acolwell: how should we
proceed?
... i can live w/ the timestamp
... i don't strongly object
... the framerate i think you can derive
... jitter, i don't know
adrianba: i'm fine w/ leaving out
those data values for now
... i'd like to see
... do you agree a method conveys more clearly than an
attribute?
... i think people assume a value from an attribute they assume
it's constant
acolwell: i know the `buffered`
attribute on a MediaElement says it's a new object each
time
... not sure about elsewhere
paulc: you said you wanted an object
adrianba: i wanted a method to indicate it's a new object
acolwell: i was using the
MediaElement as an example
... i'll take an action to incorporate those changes into the
spec
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20760
jerry: total video frames, how is that?
acolwell: originally it was
frames before decode
... theoretically displayed
jerry: these values convey
intended framerate and dropped frames
... initially we had a proposal for frame jitter
... how was that resolved?
adrianba: feedback so far, we
want to make this as simple as possible
... there's agreement on determining frames being dropped
... "how essential to applications is jitter?"
... there doesn't appear to be much support for jitter right
now
<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/610e94d71afef8168a155903fb64261c3c0ab3a2
<gitbot> 13html/06master 14610e94d 15steve faulkner: remove hgroup from element list...
adrianba: we want to support
things where there's consensus
... the question is can we make a case for jitter?
acolwell: my concern is was that jitter significant?
<bryan> jitter is an important metric especially in variable network environments
acolwell: will people understand which to use
paulc: you'll raise adding jitter later?
adrianba: rate
paulc: and later, we'll open a new bug and point back
<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06CR: 02https://github.com/w3c/html/commit/5ebde5b9f609f00548800d882e0d8b346f8d789f
<gitbot> 13html/06CR 145ebde5b 15steve faulkner: remove hgroup from element list...
acolwell: adrianba, can we do "out of order" last?
paulc: do out of order out of order?
adrianba: sure
<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=21298
acolwell: this is the media
primer bug
... i kept it open because they requested a diagram
paulc: adrianba, you sent an
email
... saying that the TF was requesting chairs do a call for
volunteers for a primer for MSE
... i responded saying i'd do that
... i haven't done that
acolwell: you were saying this
bug would be resolved by someone writing a primer
... i could resolve this as later for the primer
... this shouldn't block getting to LC
... i wanted to see i can get agreement on that
paulc: proposal to resolve as
LATER
... put it in later, or in a primer
... 21298 is resolved LATER, w/ possibility of inserting
diagram later
<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=21431
acolwell: i believe this can be
resolved
... i'm not an expert
... i believe glenn_ said the preference would be to have a
reasonable behavior
... and not have to deal w/ overlapping text tracks
... i believe we can properly handle splicing of text
tracks
... assuming we don't have to deal w/ overlapped ones
... the behavior is predictable if you have overlapped
... but it isn't optimal
... i plan to close this bug
paulc: how will you resolve this?
acolwell: WONTFIX
glenn_: does the current text cover text tracks that support/override the behavior?
acolwell: it doesn't
glenn_: i'd like to see that
acolwell: can you provide suggested text and location?
paulc: if glenn_ can give a
target and non-normative text
... saying that the format of a Text Track might override
that
<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=21536
acolwell: i think adrianba is on
the hook to provide text
... this is about origin/data handed to MSE
adrianba: we um
... talked about this in the context of
... some of the other origin related questions
... there are some aspects of the video
... element
... that depend upon whether or not the source of the data is
Same-Origin or not
... since MSE allows applications to append data to data they
have access to already, into the media buffer
... that data should be considered same origin
... we think there should be a note in the spec
... to make clear that any operations on the Media element will
be considered Same Origin
... and I just need to do the work
paulc: sounds like a
proposal
... you'll write it up?
adrianba: it's assigned to me, i will
paulc: we're waiting on adrianba in order to resolve this bug
<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=21703
acolwell: this is
non-contentious, i just need to add the text
... I just need to add `unrestricted` and then resolve
FIXED
<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=21796
acolwell: also pretty
trivial
... there's an issue box in the spec right now
... "we need to define error codes from append"
... but it isn't clear what we need to return
... we'll remove this until we get implementation
experience
paulc: so this is LATER?
acolwell: no, i need to remove text pending implementation experience
adrianba: the spec calls for a
Simple Event to be fired
... which has no way to convey additional information
... we included this issue in our original submission
... about thinking about a way to provide additional
information about the error
... we got this far w/o finding a need for it
... so we propose to remove it
... the note is asking for consumers to explain what they'd
need/why
... right now we just fire an event to say there was an
error
... and then we stop
acolwell: sometimes the error will be reported via XHR
paulc: 21796 will be resolved FIXED by removing the issue box
<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=20901
adrianba: we talked about this on
the call a couple of weeks ago
... this bug was originally filed because of the need
... when you're supporting transport streams
... to indicate if an Append() is based on where you left
off
... or resetting to a different timestamp
... and the solution was to modify Abort() to indicate why
you're stopping
... to indicate if an Append() is a continuation
... this combined with other changes
... means that ultimately we found ourselves in a situation
where
... even for formats w/ embedded timestamp information
... you wouldn't be able to do an overlapping or out of order
fragment
... w/o calling Abort()
... we found that when snapping to the latest snap test
... that the tests we built previously stopped working
... since the file format supported out-of-order
fragments
... we weren't including checks to prevent that
... we think this is a valuable part of the spec
... thus this solution for transport streams was imposing an
extra burden
... on formats that didn't require this capability
... ideally, formats that support out of order append
... would be required to take no additional steps
acolwell: it's more about no
ambiguity of steps
... in the transport case, it's unclear if it's a discontinuity
or an out of order append
acolwell: step 7 here is the crux
of the problem
... where we're detecting if the thing being appended is w/in a
range of what was previously appended
... i'm guessing that when this got implemented
... which we haven't implemented in Chrome
... things broke because out-of-order was determined
... when it wasn't before
... we could make it optional for only transport streams
only
markw: make it required for
transport streams
... i'd like to support adrianba 's proposal
... the absence of this is one of the many reasons that MPEG2
transport streams are a bad solution
... which is why other formats are better
... i was surprised that this arrived as a result of the MPEG2
transport stream
... if you need extra hoops for MPEG2 transport streams
... then add it to your list of extra hoops
acolwell: does bob or the other cable people
BobLund: the motivation for
this
... this is a response to MPEG2 transport stream
... which has a
acolwell: a discontinuity
allows
... the timestamps to just shift
... you have to see the frame before
... if you do appends right on the boundary
... it's ambiguous if it's out-of-order or not
... the rule to fix this
... appends were assumed to always be contiguous
... if this happened, you always new the append was supposed to
be adjacent
... the proposal is to make this only the case for transport
streams
... for MPEG4-ISO and WebM
... there's no need
... the only effect would be that on transport streams, you'll
have to call Abort() more often than for ISO/WebM
BobLund: you'd have to call Abort() when it's discontinuous?
acolwell: no, when you want to do an out-of-order append
BobLund: is there a way to signal
when there is a discontinuity
... strips will know that
acolwell: i was under the
impression that scripts wouldn't know
... in HLS you would
BobLund: i think that's alright
paulc: proposal is in
... in Section-3.5.7 Coded Frame Processing
acolwell: i need to look
... i need to figure out exactly where
... i'll put a note saying that for transport streams, the
behavior is slightly different
adrianba: maybe we can agree here
that we do want to change this model
... and make what's currently there not be a problem for
formats that include timestamp data
... i have concerns that just changing step 7 to make parts of
it optional
... using Abort() in this way seemed odd to me
<paulc> Step 7 in 3.5.7 Coded Frame Processing
adrianba: it doesn't feel like
you're necessarily
... sometimes you call abort when you aren't aborting
anything
... Abort() is normally for cancelling a pending
append/remove
... here you're calling it outside of that to set some flag
acolwell: i think there might be
more that needs to change
... i think there's certain state
... Abort() allows us to reset state
... if we don't use Abort(), we'd need to figure out the pieces
of the state
adrianba: we could create a new
method
... and have the bits move there
... and have it be a no-op for other formats
acolwell: i think there are a
couple of issues w/ how Abort() is being used
... we need to figure out the right separation
paulc: do we know what we're
going to do here
... adrianba, you were asking if we need a different
method?
adrianba: i was saying i think it's more than making a part optional
paulc: so, acolwell, it falls in
your court to come up w/ a proposal
... i believe that's the last one
... only other item for MSE is
... as we go to 0 bugs, do we feel we could do an LC?
... any time you do an LC, you have to ask "how long would that
LC have to be?"
chaals: 3 weeks is the absolute
minimum
... longer specs should have more
paulc: between 3 and 6 weeks
depending on size of spec
... it could be 6 months for some reason
... the TF can make a recommendation
... we'd do a CfC at the WG level
... do you have an idea of schedule
... this is April 23, will we reach 0 bugs in May?
acolwell: yes
paulc: anyone in the room think once we go to 0 bugs, we shouldn't go to LC?
adrianba: i'd like to make a
slightly different proposal
... historically trying to say we'll get to 0 bugs has been a
good way to make things last a long time
[ laughter ]
adrianba: my alternative proposal
is to say
... what we've done in this group is
... "we believe we're getting close to a LC"
... we have work to go and resolve them
... now is the time for a Pre-LC for WG members
... to make sure they've looked through it
... and filed bugs
... if people file bugs after that deadline
... those don't block LC
... the point of LC is to get bugs from outside the WG
... but we're likely to get bugs from inside the WG
... we'd commit to resolve bugs filed before the deadline
before going to LC
... and others as part of LC
<Zakim> chaals, you wanted to say exclusion period means 90 days between LC and...
chaals: shortening LC period
doesn't necessarily help you
... keep the patent exclusion period in mind
janina: you can start the patent exclusion period sooner
chaals: it's necessarily from LC
acolwell: i'd like to do it as
quickly as possible
... we made progress
... i came here a year ago and proposed this spec
... i'd like to keep this pace
paulc: where's this in the Process document, chaals ?
chaals: it's in the Patent Policy
paulc: adrianba 's suggestion is
good
... adrianba 's asking for
... Chairs to send out a notice to WG
... "we're getting close to wanting to go to LC in MSE"
... "we're declaring an X-week pre-LC period -- bugs filed
during that period will be dealt with before LC"
... "any bugs filed after that period will be dealt w/ during
LC"
... it sounds like a 3-4 week period for the X-week
... i'll take an action to take an action to discuss that w/ my
cochairs
adrianba: yes
paulc: the Accessibility people had a topic they wanted to discuss
paulc: would someone from A11Y TF like to introduce the topic?
janina: sure
... the question is
... do we need to encrypt/drm protect/etc
... the various alternative kinds of media that supplement
Video/Audio
... in the TF, we've canvased around the Group
... people who create Captions, Described Videos
... if you've read our documents, you'd know we're contemplated
other alternative forms
... e.g. a parallel sign language track would cover more
cases
... the question is that "does this need to be
encrypted?"
... no one seems to really need that
... no one seems to have a UC/need for that
... then, if we go w/ unencrypted content
... how do we make sure that if you don't do so, you
won't
... history shows that
... once you can, people check the box to encrypt
... which presents accessibility issues
... which we should probably avoid unless you need to
<paulc> rrsagent prepare the minutes
janina: i'd like to ask JF_ to
speak
... i know he has a contrary view
JF_: the issue is
... not whether they can/we can
... but whether descriptive audio/descriptive text are
encrypted
... they can be mixed in
... you have content A which is unencrypted
... but you have a secondary provider which might want to
license additional content B
... and secure their additional content
... i'd like to tease this out w/ the technical guys
... to see if this were a problem
... if we have two streams from different CDMs
... like janina, it isn't like we have definitive answers
... but we have questions to the floor
Mark_Vickers: we're talking about
transport formats
... older formats
... captions in the older standards were in band
... if things were encrypted, it was all encrypted
... the import thing is
... not whether it's encrypted
... but whether it's brought out through the standard Text
Track APIs
... then it doesn't matter if it's originally encrypted
... i don't believe we have a mandate in the spec that says you
have to do that
... you have to make Tracks
... there's nothing that mandates that the stuff comes out
markw: for Netflix, we don't
encrypt Captions tracks
... we don't see any reason to
... or reason why we'd need to in the future
... for this spec, i'd advocate not doing additional work
... w/o requirements
... i don't think we have support/needs for CDMs rendering
captions
chaals: i filed a bug on
EME
... for the case JF_ outlined
<joesteele> +q
chaals: there are third party
services that do captioning/description
... i know of services that do it
<paulc> Charles bug on tracks: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21741
chaals: i can't think of a
service that charges for it
... actually, no, i can.
... if they're charging, and if you have an encryption
api
... i'd expect them to want to use it
... i'd expect the people wanting to help people w/
disabilities wouldn't be able to
JF_: because of the possibility
of this ... that it could happen
... between a rock and a hard place
... if the answer is that if it's very easy, very difficult, or
something between
... that would help weight what to do
... if people say it's a 2 to fix (1..10), v. if it's a 8
... i'd like to understand how hard it'd be to fix
... i'm just concerned it's lingering out there
adrianba: the reason we chose not
to try to solve this problem in the first release
... was it wasn't entirely clear how we should try to think
about this
... because of support for presenting video+audio frames
... typically a UA that would process encrypted captions
... would have to have access to the captions
... we have a bug 21569
... which talks about the consequence of having Encrypted data
in the media element
<MarkS> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21569
adrianba: talks about not being
able to read data from a <video> element
... e.g. if you have encrypted <video> and you use the
<canvas> draw api
... we have a bug to add info to the spec to highlight that
case
... it puts the onus on the consuming api
... to handle cases beyond Cross-Origin
... to handle the error path when you don't have access to the
media data
... in the absence of the api
... Text Tracks either work or don't
... if a particular app doesn't mind
... it could be seemless to the app
... an app could take in band encrypted captions
... apply it to the video
... but not make it available to the text track api
... the api could not work if the UA doesn't allow access
... i don't tihnk we need to provide for this explicitly in the
spec
... once we gain more implementation experience
JF_: you're talking about Text Tracks, what about Descriptive Audio
adrianba: we believe we have support for multiple Audio streams
JF_: in that UC, your video is
encrypted w/ scheme A
... and your audio is encrypted w/ scheme B
<gitbot> 01[13html01] 15rubys pushed 1 new commit to 06feature/whatwg: 02https://github.com/w3c/html/commit/f57d22e461085c6b27e05580ebbd1dcc8e72dd54
<gitbot> 13html/06feature/whatwg 14f57d22e 15ianh: [giow] (2) Add bitcoin: to the URL scheme whitelist, by request. It's more or less like mailto:....
JF_: will that work
chaals: and you don't see that's critical today
adrianba: i don't think we need to change the spec to satisfy the requirements
BobLund: seems like there are 2
situations
... one is when the tracks are encrypted
... and one where they are not
... it seems like it's up to the CDM to handle embedded
encrypted tracks
... for the non-encrypted case
... it seems we need to specify how those are exposed by the
UA
... the assumption is that normal audio/video tracks are made
available in a standard way
... i don't think we can leave it up to the implementation to
decide which tracks are available
janina: back to JF_ 's
point
... i think we have a terminology concern here
... alternative media might be Audio, or Video, or Text
Track
... not necessarily one or the other
... both are possible
... how to make it visible
... we ask for quite a lot in UA requirements
... we don't want to just make it visible
... we also want to control
... font color, background, size, portion of resource
... i'm really concerned if we start by worrying about
encryption and what can/can't be exposed
... just because we might need it
... we're talking about the current version of the spec
... not the last version
... if we don't have demand for it
... why focus on it right now
... we have lots of requirements right now
... seems they're more important
ddorwin: you're worrying that
unencrypted text tracks might not be made available during
encrypted playback
... i believe it's implied that they would be available
... i don't know how we can
... i think we should discourage encrypting these tracks
... the biggest concern is that it will be hard to be
compatible w/ a lot of platforms
... if someone wants to encrypt, they can do out of band
traps
... and use WebCrypto for the same level of protections
mjs: question... maybe someone
knows the answer
... maybe people who know more about media production
... in DRM production on Web today
... w/ plugin today
... are captions today encrypted?
... if they aren't encrypted today
... i'd think there's very little demand for HTML5
solutions
... and perhaps not to be supported
glenn: in encrypted transport of
classic format
... it's encrypted
... in other forms, it's likely not to be
... except for the third-party encryption case
joesteele: when we have encrypted
content
... we duplicate them and send them out of band in unencrypted
form
... on a world-wide basis, i'm not sure if everyone is doing
this
chaals: my impression is that
there isn't a huge amount of alternative/extended content being
encrypted
... a concern i have today
... is original UC
... the point of being able to encrypt content is that content
providers have it as part of their business model
... it seems odd to say that a content provider has the right
to do this
... but a disability provider doesn't have that right
... it seems back-ass-words way to do
JF_: what chaals said
... that we don't have demand now is great
... but that door seems really wide open
... too often, A11Y is chasing after the bus has left
CyrilRa: at XXX we're aiming at
supporting all 3 modes
... embedded in the video
<CyrilRa> sorry about that… We are embedding CC within video
<CyrilRa> hence being encrypted
chaals: and thus encrypting them?
<adrianba> that assumes that it isn't feasible to do this - my assertion was that the spec doesn't need to change to support this - if there are specific changes someone thinks is needed then that should be proposed concretely
<ddorwin> CyrilRa: What container?
joesteele: w/ our DRM, we support
encrypted text data in the streams
... judging on the number of bugs in the area
<CyrilRa> MPEG2-TS and MP4
joesteele: i don't think anyone
is using it
... because i don't think my code is bug free
<CyrilRa> using HLS and HDS
joesteele: people use 608/708 data, captions encrypted because stream is encrypted
paulc: so you're doing the
opposite
... of markw
<ddorwin> CyrilRa: AFAIK: You don't need to encrypt the all streams in a fragmented MP4.
joesteele: we're not doing it
paulc: someone using your information could do it
joesteele: correct
... if we were to provide an API for the CDM to extract that
information
<ddorwin> (Not sure about HDS's requirements.)
joesteele: then i don't see the
point in encrypting it
... someone said you could use WebCrypto and it would be just
as secure
... i'd agree w/ that
markw: we don't encrypt the
captions and don't see the reason to
... for audio/video assistive content
... i don't think we have many
<joesteele> s/I don't think anyone is using it/I am not sure it is being used/
markw: for captions, if you
really want full DRM, you'd be asking the CDM to decrypt and
render
... that would be a big additional requirement on the
spec
... the only encrypted caption is whether they're embedded in
the transport stream
... MPEG2 brings a number of hoops
... if you're given a bunch of hoops and implementing APIs in
CDMs
... or just pulling the captions out at the sending side
... I know which makes more sense
... the APIs don't exist in protected media pipelines today
adrianba: agree w/ what markw
just said
... i don't think anything in the spec today prevents someone
from doing it
... i don't think there's anything necessary to add to enable
this capability
... if anyone has a concrete issue not covered by the
spec
... i'd like to have it raised
paulc: as the queue is empty,
i'll move along
... janina, and JF_, you asked for opinions on the current
spec, and from content providers
... I think we've come close to meeting your initial goal
JF_: hearing it isn't a huge
fire
... i'd like to say thanks to the technical guys for lettings
us talk through this issue
janina: i'm good
paulc: i'd like to remind people
of what adrianba said
... when you're working in a TF environment
... the best thing to do is give it a concrete bug
... with a pointer saying "this is a bug here, please fix
it"
... i'd like to encourage the A11Y TF to treat them the same
way as you
... and i'd like to praise chaals for raising a bug to consider
the issue
[ Coffee break ]
<paulc> test
paulc: two items
... deep dive into EME bugs
... - take an hour or so
... take a look at the situation of FPWD of EME
adianba: we'd like to start with
consistent interoperable errors
... here is a UC for sites to report error conditions back to
their hosts
... XXX
<ddorwin> adrianba: Call to ACTION: Review the content protection systems you work with, and collect the error codes that you might want to work with and report those.
ddorwin: we don't necessarily need to start w/ the existing bugs
<paulc> bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798
ddorwin: not trying to force error codes - round peg square holes
paulc: 21795
... 16737
... 16617
Daniel_Austin: Daniel_Austin,
PayPal
... i think we might want to provide a uniform set of status
codes
... so users and sites can do diagnostics
... working w/ the WebPerf WG
... i posted a list of status codes to their group
... now's a good time to try to get them synced
paulc: has anyone else from the
TF looked at this?
... I assume one of the parts of the TF will meet next
week
... adrianba did you have a time table?
adrianba: we have lots of bugs
chaals: yesterday would be great
[ crickets and popcorn ]
joesteele: one of the error codes
in there
... service error
... i shouldn't have gone through the existing errors
... but reported the actual errors we use
... one distinction in errors i'd like to make
... is customer service errors
... and cdm errors
... an end user error v. a customer's license server triggered
failure
Daniel_Austin: WebPerf errors don't distinguish that
joesteele: we could distinguish errors by domain
Daniel_Austin: great
suggestion
... i don't want an incomplete set of status codes coming out
of perf
paulc: surely WebPerf isn't
trying to make the one-ring-to-rule-them-all of error
codes
... this is about the distributed web
... we want a spec that says these are some error codes
Daniel_Austin: we recommend the
IANA registry for HTTP status codes
... we proposed an additional set of error codes for DNS
errors
... and SSL errors
... and a set of errors for when a user abandons a page
... we haven't taken into account adrianba 's classes
... i don't want errors scattered across other specs
<ddorwin> Currently being displayed: http://lists.w3.org/Archives/Public/public-web-perf/2013Apr/att-0007/WebRequestStatusCodes4.html
paulc: what about "HTML spec" errors?
Daniel_Austin: if you'd like them available to the WebPerf NavigationTiming spec
<arun> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html
Daniel_Austin: WebPerf WG has
published specs for letting apps read counters from the
browser
... navigation timings
... resource timings
... a new spec for error logging
... [for when something doesn't load from a CDN]
paulc: what's the link to the
logging spec
... and how does it relate to what other WGs are trying to
do
Daniel_Austin: i'll post a link
to the spec
... it doesn't have much beyond the error codes
paulc: does this api simply return an error?
<ddorwin> Web Perf Error Logging spec: https://dvcs.w3.org/hg/webperf/raw-file/3298bdfd617b/specs/ErrorLogging/Overview.html
Daniel_Austin: it returns a list
of error codes, and the objects that returned the error, and
when
... there are two cases
... one is page load
... and another is for when the browser crashes
... we proposed a limited subset of the data
... that would be persisted
... that would be returned to the source site later
... that case is much more difficult
... we've decided not to specify a specific persistence
mechanism
paulc: i'll end this discussion
now
... we'll give you 15 mins tomorrow
... to give an intro to this spec and what it would mean to the
HTML5 UA
... we have time in tomorrow's schedule
... i won't disagree w/ you
... that if the implications are close to what i said
... that this will have implications to what a UA would have to
implement
... we'll talk at the end of today or tomorrow morning
... I tried to move of 21798
... and joesteele spoke on CDM
... which led to confusion on CDN
... so, to 20688
<joesteele> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20688
adrianba: i think we need to
start w/ a bit of history, unfortunately
... we made a bunch of changes over time to the spec
... that brought us to the situation
... in our original submission to the WG
... we had this notion that during the acquisition of a
license
... the CDM could force the browser to fire a message to the
browser
[ long complicated and roundabout ]
adrianba: it's in the bug
... comment 2 in the bug says what i said
... we modified the API to use a more object oriented
approach
... this means that, the way the messages/events are
fired
... is a little different than we intended at the
beginning
... we talked about it a few times on the call
... i summarized how we were thinking about the model
... but it isn't what's described in the spec
... this value is about one of the events
... keep "KeyAdded", be more precise about what it's for
... in my model, KeyAdded means "license acquisition is
complete"
... think about it like progress events, it's like "load
event"
... we're done loading, and you can move on
... KeyAdded isn't saying that a key is added
... but that the conversation w/ CDM is finished
... ddorwin said how do you deal w/ license renewal?
... sure you ended initial conversation
... but later during playback, you need to refresh the
license
... and i suspect markw is going to comment as well
... and final comment on this, this model is related to some of
the other bugs
... bug 19208
... - asks the question about when KeyMessage should be
fired
... bug 16553
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19208
adrianba: - asks the question about a NeedKey event should be fired [an event before this whole process]
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553
adrianba: resolving this
lifecycle is the largest unanswered question of the spec
today
... that's the setup
... i was hoping people would weigh in w/ other questions we'd
need to answer
... or suggestions about how we solve this
markw: i wonder whether we should
take the approach
... of defining an explicit state
... and defining a variable w/ the state
... [a state machine]
... i think we could try to make that more concrete
... not sure what the states would be
... maybe 3, maybe 4
... i think that would make it much easier to talk about these
things
ddorwin: even if we had a state
for a session, there may be multiple message transfers in
progress
... between a CDM and a License server
... you could have two renewal messages for different
keys
... if you had a session to represent communication between a
CDM and a License server
... you could have two in progress concurrently
markw: on that point
... i think we could take the approach of "what are all things
a CDM could want to do"
... or "what is the simple state model that makes sense - and
make CDMs work w/ that model"
... if the CDM wants to do two things at once, it constructs a
message w/ two things in it
... instead of us imagining everything a CDM might want to
do
adrianba: i think we need to
support two or more pending transactions to license
services
... no constraint on count to license server or transactions to
a license server
... during decoding, you could encounter a need for another key
from another license server
... we do need to have multiple conversations w/ a license
server in flight at one time
... at the beginning
... at least, at some point, i had in mind that a session
represented that communication
... you'd have one per conversation with a license
service
... i think one of the problems is that we've slightly
overloaded what we mean
... with a license service session
... and think we may need to break it into multiple models
<Zakim> ddorwin, you wanted to ask What specifically does having a "completed" state gain us?
<ddorwin> What specifically does having a "completed" state gain us?
ddorwin: you completed
... and send multiple messages
... what do we get from that
<ddorwin> Maybe states for an "initialized" and "has key(s)" would be sufficient?
<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20689
ddorwin: there's a bug about being told when you have nothing else to send to the server
joesteele: if i have a session
open
... and i've done my initial exchange w/ a license server
... i do one, two, three exchanges
... and then my license expires, maybe this is key
renewal
... the CDM knows i need to renew it
... can it just send a request
... is the app ready to accept that?
... if i have multiple sessions going on
... they can all be in this state at the same time
... they're all independent as far as the application is
concerned
markw: to adrianba 's
concern
... about multiple sessions
... and key messages
... we left it open for different CDMs to do it different
ways
... you could file NeedKey
... or ...
... I think it's best to just pick a model
ddorwin: i think with CreateSession we said there was one way
johnsim: it's important that the
states the CDM goes through
... that the application needs to know about
... are signaled/ known about by the application
... w/o a state diagram, it's hard for the application
... i think that's the missing piece
... wrt how a session is defined
... i think you can't let the way a session is defined be CDM
specific
... because then an application won't be able to have a CDM
agnostic behavior
paulc: you're saying something
like what markw said
... abstract to the simplest number of cases
... and then a CDM may have to change its behavior to match our
model
johnsim: two things
... 1. define the states any CDM will go through that an app
needs to know about
... - CDMs can go through states an app doesn't care
about
... for any state an app needs to know about, document it in a
generic way
... providing events for the application
... 2. define it in such a way, that two different CDMs by
different providers
... behave the same way wrt event pattern
paulc: if we take it at face
value that you're right, johnsim
... then we need to know which states the App needs to know
about
... what are those states?
johnsim: the current spec doesn't
define those states
... as much as they're implicit in the event model
paulc: and that was markw 's
point
... if we defined the points, it would help
adrianba: i like markw 's
suggestion of having a state variable
... with clearly defined values
... and i think ddorwin 's suggestion of having
... what i described as Finished
... actually indicate "reached steady state"
... the proposal i sort of hinted at in the bug
... was to provide a set of events based on progress
events
... idea would be, an event fires
... to indicate that the session was initialized
... "load start" equivalent
... what we have for KeyMessage would be the equivalent of
"progress"
... and we would fire an equivalent of "loaded" for when
KeyAdded was in the proposal
... to indicate that the session was established
... you may still get future key messages for renewal
... but the initial conversation was done
... i'm not sure we'd need to be explicit about Expired or some
other reason for a Renewal
<Zakim> ddorwin, you wanted to ask What states do we need/care about? Do we need states if the application knows exactly what it needs to do for a given event? Rephrasing what I asked
ddorwin: it's currently
stateless
... you get a key message
... get something from the server, pass it back
... works for initialized
... Otherwise, i like adrianba 's states
adrianba: one reason i think we need something like loaded
<ddorwin> What states do apps need/care about? Do we need states if the application knows exactly what it needs to do for a given event? Rephrasing what I asked earlier, do we need one of those states to be "closed"/"ended"? If not, then just responding to events may be sufficient.
adrianba: is one of the bugs i called out before
<Zakim> markw, you wanted to say how keyrelease fits into this model
markw: if we define a bunch of
states
... and discover that the states are implicit from the message
sequence
... we could leave them in or rip them out
... adrianba mentioned keyrelease
... in that state, if the CDM supports "proof of key
release"
... then it's in the position to give you that proof
... and we define what happens for that state transition
paulc: doing a state transition
model is important
... so that people can understand what's going on
markw: discovering if the
implicit thing works or not
... is to be explict
joesteele: adrianba 's
point
... there's one state needed that isn't implicit
... if a CDM already has a particular key w/o key
exchange
... then you want the application to not wait to get a
keyrequest message
<ddorwin> My summary of (my understanding of) Adrian's proposal:
<ddorwin> States: Uninitialized, initialized ("loadstart"), keymessage ("progress"), keyadded replacement ("loaded")
<ddorwin> I think the last three might be events. The first state is probably implicit.
<ddorwin> The keyadded replacement could be useful for a case where the CDM immediately initializes a session with existing material.
ddorwin: the events in quotes are
video equivalents
... keyadded is already going to be renamed
paulc: we need to decide if
someone is going to write a proposal
... someone writes a state diagram and shows if it maps
... and if not ...
... will someone do this?
[ paulc lists a bunch of bug numbers ]
paulc: there's probably a bug on
key release
... adrianba, ddorwin, do you know the next steps?
adrianba: it feels like we've
made progress in this discussion
... i think the editors have enough to get together
... to make a proposal back to the group
johnsim: one of the things, you
already have a key
... e.g. from a store
... there could be a case where the app wants to force the CDM
to make an acquisition
... a CDM could make a License server request
... but CDMs can also make a disk protected key
... some applications might want to force the CDM to get a new
key from the License server
... if you support getting a key from the disk
... you need to give the app a way to specify if it permits
using a key from the disk
adrianba: i'd like johnsim to
file a new bug on this
... to make sure we don't lose it
... proposal i will then make in that bug
... maybe when the event fires to indicate that the session is
loaded
... it's possible we want to provide some indication of how it
got to that point
... e.g. if it did it through cached key material
... the application could do something
<ddorwin> alternatively, tag the keymessage to indicate "already in progress"
joesteele: specific case is renewing a set of entitlements before going offline
joesteele: if i'm about to go
offline
... i thought about offline content long ago
... and decided not to file it
... because offline playback in the browser wasn't a UC under
discussion at the time
paulc: offline entitlements are different, or just cover more time?
joesteele: cover more time
paulc: you'll be disconnected,
and can't get a renew
... you'd say "give me one now", and it will last longer
johnsim: even in the live video
case
... or OnDemandVideo
... you're playing content from the web
... you're allowing for local key storage
... the main reason why i felt it needed to be addressed
... i knew in general, such a UC is very common in DRM
systems
<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=16540
johnsim: we shouldn't restrict what we're doing in EME to what we're trying to do now for OnDemandVideo
adrianba: this is one joesteele wanted us to talk about
joesteele: my concern with
this
... the bug is confusing to read now
... about how you're supposed to use the key system
... 1. can we roll capabilities into it
... it was split out, and we decided not to do that in the key
system
... 2. verisioning
... UC was to request a specific version of a CDM
... a particular version of a CDM may have a feature an earlier
one did not
... a particular version of a CDM may have been breached
... - want to avoid using those
... i was thinking we'd register com.adobe.access and
com.adobe.access.v{n}
... so we could request the latest one and the generic
one
... does that make sense?
<adrianba> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#key-system
paulc: is versioning mention in the bug?
ddorwin: you have to look at the spec
<gitbot> 01[13html01] 15rubys pushed 2 new commits to 06feature/whatwg: 02https://github.com/w3c/html/compare/f57d22e46108...31bbb5f68cbf
<gitbot> 13html/06feature/whatwg 14e2287ae 15ianh: [e] (0) Try to clarify use of the term 'expose' in the WebIDL sense....
<gitbot> 13html/06feature/whatwg 1431bbb5f 15ianh: [e] (0) Remove redundant requirements....
paulc: your proposal was
appending something to example com.example.somesystem.1 and
com.example.somesystem.1_5
... this is obscure being linked to this particular bug
adrianba: i pasted another link
that talks about this
... joesteele was talking about isTypeSupported()
... the original design is that
... you could make a request isTypeSupported(
com.example.somesystem )
... that would return true if the general system is
supported
... if no, you wouldn't interrogate further
... if yes, you could ask about v1, v1.5
... i think the question raised in this bug is
... do we need to add
... text to the spec that describes this more
... gives greater guidelines
... is this pattern something that's actually needed
... or is it something down to the CDM?
... it's unlikely that you'd write code that follows this
pattern in a generic way
... since the capabilities of different versions will be
different across different systems
paulc: joesteele, is the system powerful enough to use in the way you want to use
joesteele: yes, it's probably
overkill than what we'd want
... we could live w/ an explicit string match
... having browsers do this is more than we'd need
chaals: this code assumes linear
progression
... and you want hasMinimumVersion()
... is that likely to be a pattern?
paulc: i'll take anything after version 3?
chaals: if IE3
adrianba: and the people that do,
we're trying to shoot
... it's no coincidence that this is tied to the other bug
about capability detection
... no coincidence that we'd park that bug until we decided on
what we need to detect
... maybe we can say we don't need this sophisticated
approach
... maybe we can push toward feature detection instead of
particular versions
chaals: did you discover trying
to push people to feature detection
... because people did version detection?
... are we opening up a way for authors to make mistakes
early?
adrianba: maybe
... i'd rather try to catch it early than try to predict and
get it wrong
chaals: i think i'd like to do the same
paulc: enough discussion on
16540?
... sounds like simple string matches
... if we aren't doing capabilities
... after that, you can use another mechanism
... next is 19009
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19009
adrianba: we discussed this on a
call
... the minutes didn't really
... describe a conclusion
paulc: these are the minutes in comment 6?
adrianba: yes, but it points to a
not useful, but lengthy discussion
... conclusion i think we reached
... was that we should add a note to the spec
... that some implementations might require the media keys be
attached to a media element before the event sequence would
take place on a session
... this is somewhat tangentially related to the original
bug
... i think that conclusion means that we're ok to
... follow the pattern we have right now
... make it so that implementations may throw an exception if
they don't support media keys being shared across multiple
elements
... that's likely for initial implementations
... important thing is that we need to add a note about
requiring attachment
paulc: action?
adrianba: action is to edit the
spec w/ the note
... just wanted to clarify that this is the next action
... and give people a chance to comment if they disagree
paulc: any last things to address?
ddorwin: 20335
<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20335
ddorwin: canPlayType
... supports "", "maybe", "probably"
... initially in MSE, we have isTypeSupported
... should we also return boolean?
... does anyone support canPlayType()s 3 states, none of which
are true
... anyone have an opinion?
paulc: if we change it to a boolean, the probably case goes away?
[ maybe ]
paulc: what's the UC for Probably?
johnsim: Probably/Maybe
concepts
... is ...
... you can't tell from media util you play it whether you can
really play it
... it isn't just searching for attributes
... i don't see a case where any uncertainty should
reside
... as to whether or not content is decryptable by that key
system
... you don't know if the license server will honor the request
for the key
ddorwin: we pass in the container as well
BobLund: canPlayType
... probably is meant to say "does the UA support mime
type"
... whether UA can decrypt it is irrelevant to canPlayType
adrianba: i wanted to describe
two alternatives
... spec has isTypeSupported as a boolean
... you use this method to answer
... "does the UA support decrypting content in this format
using this content protection system"
... if the UA says "probably" or "maybe"
... and you add in the content type
... and key system
... might you get the same answer as canPlayType
... otoh, supporting canPlayType and isTypeSupported
... then a bool would work
... what does an app do differently if it sees maybe or
probably?
... it's just going to try to play the content
... if you know definitively that it won't work, you probably
try the next content
... but if you know it's potentially supported
... then you probably just try to play it
<ddorwin> There are probably less random formats to deal with in EME as well.
joesteele: we'd probably prefer a
boolean
... yes it may fail
... it may mean it can't play that instance, but just that
instance
paulc: hearing a bool pref
... anyone can give us an example of why it shouldn't be a
boolean
joesteele: you ask about a mime type
paulc: and i can give you a
mislabeled stream
... ddorwin you asked about this type
... did i get you an answer?
... and don't say "probably" or "maybe"
[ laughter ]
<paulc> http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0123.html
paulc: we asked about whether
something was in scope
... eventually ruled it was in scope
... whether FPWD contained enough to be implemented
interoperably
... we asked for clear and specific bug reports in Bugzilla by
Feb 15
... once that was complete, we were going to seek answer from
editors on how to proceed
... process bar for FPWD is fairly low
... when we reevaluate request to publish
... we'd only consider things based on bugs
... but no requirement of reaching 0 bugs
... TF received approximately 13 bugs
... in the window
... i provided a summary on the Media TF
<paulc> http://lists.w3.org/Archives/Public/public-html-media/2013Apr/0089.html
paulc: my first email goes over
the history
... it's a bit hard to give concise status of bugs
... it's hard to handle REOPENed
... the respondent disagreed with being able to take a document
to FPWD with bugs open
... some respondents have commented on everything as "i
disagree"
... which makes it hard to have a dialogue
... for 20944
... - we left it open and proposed to add a SOTD
... i think we did this for 2 or 3
adrianba: 3
paulc: we believe there's
technical merit in the comment
... but we don't believe it should stop us from going to
FPWD
... we resolved several as WONTFIX
... i included link to bug and editor's response explaining
why
... - which typically includes the link to the minutes
... here's one w/ needsinfo
... - which was reopened w/ no new info
... a couple were resolved worksforme
... - we took an appropriate action
... 20965 and 20966 were SOTD items
... one we resolved as a duplicate
... and one as later
... several of these bugs have been reopened by the
correspondent on a regular basis
... even if the correspondent didn't change the status of the
bug
... all of these bugs are attempts to characterize why not to
do EME in the HTML WG
... there are more filed after the bug-window
... there are probably 4 or 5 more
... the people against this work being done in the WG
... when their current arguments fail
... they find new arguments
... the TF + editors have responded to chairs
... based on the bugs in the window to Feb 15
... i think it's germane for the chairs to review if the bugs
have been dealt w/ adequately
... and decide if we can replay the CfC
... or decide if the document can be published
rubys: i don't think CfC is the
right step
... we don't need Consensus per process
... having read the bugs, i don't think we have questions
paulc: i want to be fair to my
cochairs and apologize to the TF
... this has been on my plate for a while
... i told rubys and mjs that i sent this after lunch
... the appropriate step is for chairs to take this under
advisement and report back to the WG
... mjs, there's a lot of reading
... do any of the 3 editors of EME want to comment?
... did i summarize this accurately?
adrianba: yes, good summary
... we call out 3 of the bugs in SOTD
... two issues:
... 1. degree to which spec supports interop between
implementations
... 2. issue around privacy considerations
... from discussions we've gone through these bugs
... i think we've made progress on privacy
... my suggestion for privacy is to add a section to the spec
which is privacy considerations for CDMs
... people in WG asked if the current API would support some
privacy related situations
... some of the cases I believe are already handled
... beyond guidance to CDMs
... which we'd add in an informative way
... does anyone see API changes necessary for privacy
aspects
paulc: has that direction been reflected in the bug at all?
adrianba: no, we need to update the bug
paulc: that would be useful, if
you could do that post-facto to this discussion
... chairs will use my summary as the response to the CfC
... and we'll get back to editors+TF as soon as possible
plh: if i heard chairs
correctly
... we may not have a new CfC
rubys: statement i made, not a chair statement
plh: my concern is if it will surprise the group if we don't have a CfC
mjs: we have past precedent for
CfC to publish a WD
... and having done a good faith effort, we said "with these
addressed, it was ok to publish"
... if we wanted to follow W3 process
... we could have a formal vote
[ paulc reads from previous chairs CfC response ]
rubys: i sent an email on the
24th
... ~consensus is not a requirement for publication~
steve: are chairs saying
... there will be a FPWD
rubys: still deciding
steve: and that decision will not be a CfC?
rubys: my input is it probably will not be
paulc: it won't be public
wseltzer: Wendy Seltzer
... noting that the response to several of the bugs
... ~CDMs are out of scope for this document~
... several seem to be things people are complaining
about
... are things required of CDMs
... but not things above them
... would it be ok for them to file bugs asking for CDMs to be
brought into scope
<rubys> http://lists.w3.org/Archives/Public/public-html-admin/2013Apr/0053.html
wseltzer: this is requiring activity but not specifying it
paulc: i'd like to thank chaals for his leg-work
[ applause ]
adrianba: it's true there were a
number of bugs
... commenting on CDMs being out of scope of the EME spec
... it's true that this is the design of the EME spec
... EME is designed to abstract away CDMs
... to provide a common api for CDMs
... and provide a common api for that abstraction
... W3 decided that such an API was within scope for the
WG
... EME spec is a solution for the problem
... it isn't the only way to solve the problem
... someone who believes the full capabilities should be w/in
scope
... may write the spec
... to try to address a spec that by design isn't in
scope
... is essentially saying throw away the spec and start
again
markw: we could add something to
say what we mean by CDMs being out of scope
... we don't define the APIs that the CDM might support
... it has key messages, we talk about a state machine
... we say CDM is out of scope
... but we define a bit about how you talk to it
... it sounds like defining part of CDM
mjs_: re: what is exactly
required for CDMs
... i think there's one bug left open
... with an issue note in the spec
... 20944
... EME sure do more to ensure CDM level interop
... there's been a lot of discussion in that bug
... many of the other bugs were roundabout ways to get at the
same issue
... i think it's best of have one bug for that matter
... ---
... a more procedural issue
... 21016
... ClearKey
... - i don't care much about the bug actually
... our usual approach for LATER is to use only for "not this
current version of this spec"
... i assume we'll have implementation experience by CR
... i'd propose keeping the bug open
... and having an implementation marker
chaals: instead of writing an
entire spec from scratch
... they could propose a modified version of the spec
... which modifies the scoping
... if you modify the proposal for a tower
... to have the tower have an antenna on top
adrianba: could you start from
EME and add in a CDM
... and remove the abstraction of CDM
... sure
... is that different from starting from scratch?
... i dunno
paulc: you guys are making it hard for me to recess by 5pm
chaals: if you want to make a
smaller change to the scope
... then the difference becomes more interesting
paulc: no one has tried to ask about an extension spec to an extension spec
[ laughter ]
adrianba: mjs_ made the point
that there's still a bug about part of this
... many of the bugs essentially raised the same point
... about interop
... between UAs
... and it's a valid issue
... the bugs wseltzer mentioned where CDMs were indicated as
out of scope
... asked for essential design changes
... my position is
... if i were to solve for those bugs
... i probably wouldn't start w/ this spec
paulc: thank you Josh_Soref for scribing
[ Applause ]
paulc: do we need to retrace our steps with you?
Daniel_Austin: everything is locked at 5pm
paulc: and we're in a different room?
Daniel_Austin: yes, you'll be
escorted to the new room like today
... please keep your badges
... there's a reception tomorrow
[ Adjourned ]
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/HTML Weekly Teleconference/HTML Interim Face to Face/ Succeeded: s/ok/ok, ruby,/ Succeeded: s/Topic: CR and Testing// Succeeded: s/ohters/others/ Succeeded: s/re:/c. re:/ Succeeded: s|/|?| Succeeded: i/think we can do Microdata first/Topic: Getting Microdata to CR (Editorial team) Succeeded: s/See // Succeeded: s/proces/process/ Succeeded: s/critera/criteria/ Succeeded: s/TestHarness.s/TestHarness.js/ Succeeded: s/`ben`/Bin (Hu)/ Succeeded: s/thatr/that/ Succeeded: s/../.../ Succeeded: s/master/master - where everything goes first/ Succeeded: s/-// Succeeded: s/-// Succeeded: s/-// Succeeded: s/crowd/crowd-/ Succeeded: s|Topic: Status of HTML 5.1 and Canvas open bugs|| Succeeded: i/Topic: Status/[The search engine and other processing implementations of microdata are an example of important but non-browser implementations, and on the other side so are code generators which actually create microdata e.g. for schema.org] Succeeded: s/ack// Succeeded: s/sylvia/Silvia/ Succeeded: s/of/to/ Succeeded: s|MSE bugs; http://tinyurl.com/6pdnzej|-> http://tinyurl.com/6pdnzej MSE bugs| Succeeded: s/XX/jerry/ Succeeded: s/XX/jerry/ Succeeded: s/to/in order to/ Succeeded: s/htis/this/ Succeeded: s/XX a bit/parts of it/ Succeeded: s/pre-LC period/pre-LC period -- bugs filed during that period will be dealt with before LC/ Succeeded: s/foliet/johnf/g Succeeded: s/johnf/JF_/g Succeeded: s|video/audio|captions| Succeeded: s/encrpyted/encrypted/ Succeeded: s/BobLund/glenn/ FAILED: s/I don't think anyone is using it/I am not sure it is being used/ Succeeded: s/pulling it out yourself/pulling the captions out at the sending side/ Succeeded: s/stuff bugs/force error codes/ Succeeded: s/squareholes/square holes/ Succeeded: s/posed/posted/ Succeeded: s/68/88/ Succeeded: s/three/two/ Succeeded: s/not get/not wait to get/ Succeeded: s/want/- want/ Succeeded: s/neede/needed/ Succeeded: s/q// Succeeded: s/15/13/ Succeeded: s/dialog/dialogue/ Found Scribe: Josh_Soref Found ScribeNick: timeless Present: adrianba chaals Jungkee_Song Bryan_Sullivan Jonghong_Jeon Found Date: 23 Apr 2013 Guessing minutes URL: http://www.w3.org/2013/04/23-html-wg-minutes.html WARNING: No person found for ACTION item: on kris krueger to make sure that the organizational structure of github test suite is well documented [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action03] People with action items: kris krisk krueger robin sam WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]