SVG Working Group Teleconference -- 20 Nov 2008

<trackbot> Date: 20 November 2008

<shepazu> SVG 1.2 has entered PR phase (yesterday). Announcement: http://www.w3.org/News/2008#item192

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

Marketing SVG

DS: because we're going to recommendation hopefully some time in mid december
... we're going to make a "press release"-like press release, but we're not going to spend the money to send it out over the wire
... since it's not likely to get picked up by news agencies in december
... we think it would be better to have one in january
... we don't want to hold back the spec for obvious reasons
... we need some news in order to have a reason to have a press release
... things like "going to rec"
... in this case maybe a good press release would be "last month we went to rec and we have gotten these other standards bodies - MAE, JIS, ITU - who are interested in ratifying svg as part of their standards as well"
... to show wider support for svg
... thoughts on delaying a press release until jan/feb?

CL: if we have to do that, then we might put out an improved test suite, since we've only snapshotted it
... plus more implementation report
... that'd be (faintly) newsworthy
... we'd've demonstrated it's interoperable

DS: might be good to pull in the results from other browsers, too
... e.g. chrome, safari, firefox
... we'd prepare all the things required for a press release

CL: but it'd get faxed or whatever

NH: i think that's not a problem for ikivo, but i'll check with marketing

<ChrisL> so there would be the web version, for going to rec; and a newswire update on it, in january

AG: fujisawa-san will have to ask his marketing people

DS: please get back to me about that, and with testimonials
... we'll reuse those testimonials in the actual press release
... over the next few weeks i'll be sending ideas to the list and inviting feedback on testimonials, which we can talk about later

Review of the Selectors API spec

http://lists.w3.org/Archives/Public/www-svg/2008Nov/0057.html

DS: the thing erik noted was they've removed support for selecting on namespace
... this means if you have mixed svg/xhtml stuff, you wouldn't be able to select only on svg:a

CL: given that css wg has identified css namespaces as a stable spec, i think we could argue on that basis that it should be supported

DS: we can't ignore the fact that namespaces exist
... we should also review the spec for anything else

CL: someone to do the review?

<scribe> ACTION: Erik to review the selectors-api LCWD [recorded in http://www.w3.org/2008/11/20-svg-minutes.html#action01]

<trackbot> Created ACTION-2347 - Review the selectors-api LCWD [on Erik Dahlström - due 2008-11-27].

<scribe> ACTION: Doug to review the selectors-api LCWD [recorded in http://www.w3.org/2008/11/20-svg-minutes.html#action02]

<trackbot> Created ACTION-2348 - Review the selectors-api LCWD [on Doug Schepers - due 2008-11-27].

<scribe> ACTION: Cameron and Doug to test simultaneous actions [recorded in http://www.w3.org/2008/11/20-svg-minutes.html#action03]

<trackbot> Created ACTION-2349 - And Doug to test simultaneous actions [on Cameron McCormack - due 2008-11-27].

trackbot, close ACTION-2349

<trackbot> ACTION-2349 And Doug to test simultaneous actions closed

AG: when should comments be in by?

DS: december 12

<scribe> ACTION: Anthony to review the selectors-api LCWD [recorded in http://www.w3.org/2008/11/20-svg-minutes.html#action04]

<trackbot> Created ACTION-2350 - Review the selectors-api LCWD [on Anthony Grasso - due 2008-11-27].

SVG 1.1 Errata

AG: due to tiny i haven't done much on errata lately
... i've started integrating the proposed errata into the 1.1 spec

<anthony> - Linking in a text environment

<anthony> - feFlood in attribute

<anthony> - Filter subregion

<anthony> - Cleaning up the wording of the underlying value being the identity transform

<anthony> - Start and end incorrectly described for text

<anthony> - Typo 'effect' instead of 'affect'

<anthony> - Incorrect reference to solidColor element

<anthony> - Capturing pointer-events with a zero opacity mask

AG: these are the ones that have been integrated

DS: how many more are there?

<anthony> http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml

CL: we should publish new errata with any new ones, leave it for a bit, then publish a 2ed of 1.1 that includes all the errata we have to date

AG: there's been a link from the 1.1F spec to the errata for a while

<anthony> http://www.w3.org/TR/SVG11/

AG: there are still 14 errata we need to go over, draft ones

CL: we need to get the draft ones up to proposed

DS: how about next tuesday we start going over these draft errata

CM: some of these errata are just placeholders and haven't been done yet

AG: this document is in the old repo, we should move it over to the new one
... the errata document covers all specs, so i'll have to pull the bits out that are related to 1.1F

<scribe> ACTION: Anthony to extract out the 1.1F errata items and add them to the public repo [recorded in http://www.w3.org/2008/11/20-svg-minutes.html#action05]

<trackbot> Created ACTION-2351 - Extract out the 1.1F errata items and add them to the public repo [on Anthony Grasso - due 2008-11-27].

Test suite

CL: we can package up what we have (that we used for the CR period) and that's the latest release
... or we can sit back a bit and figure out which of the drafts we can make work and push those forward
... we've said "here's a beta, here's a beta" so it's probably good to publish something final with what we've used for testing implementations

NH: we found some minor errors in the tests
... what should we do with these?

CL: raise an issue on each one and we'll discuss it

DS: we should look at an improved test harness

CL: i'd be interested to see that
... the existing one [MWI one] assumes that html forms are available

DS: we can make an svg framework

NH: that'd be good i think

DS: might need changes to the tests themselves

CL: given that the forms part is just for reporting test failure, you could postURL() and some scripts to do this

DS: or an <a>
... so we'd need something to transform the tests into this framework
... we should have criteria for making tests incredibly obvious for when a test doesn't pass
... like e.g., if at all possible, the background of the test should be red if it does not pass

AG: in some cases this can't be done

DS: but whereever possible
... if not, then do whatever needs to be done
... so many of our tests are visual
... sometimes dr olaf has made tests where something is a certain shape/dimensions and red, and overlap a green one with that

AG: so using red as an indication for failure
... i think it's a good idea

CM: i don't think it's a huge deal to require that the tester can distinguish red from green
... i like the idea of automating test criteria checking and making tests report this via a colour

CL: i'd be worried about making existing tests require scripting
... for example a simple test for bold text, you'd need to script to look through the dom etc.

DS: but for those tests already using scripting we can take advantage of this fact
... for tests that need a reference image, instead of making a snapshot of the entire test, we should include an image within the test itself to show what something should look like

NH: i'd like explanatory text in the slide itself

DS: so yes we should write some guidelines, and use these as part of judging whether these tests are added to the test suite
... some tests will have to be really complicated, but having smaller tests would also be good

CL: if you have smaller tests you have more of them, which might be a disadvantage
... a test should say first what it's testing, then whether it passes, then it should give all the details of who it's doing the testing

DS: i agree, but would put the pass criteria first

AG: in the template there should be a spot to fill in the pass criteria

DS: that's a good idea
... we should also include links to the spec that describe what's being tested

AG: the xslt for generating the test suite could easily pull out fields like this

DS: this'd also help when judging whether the test is good or not

<shepazu> ...and for test coverage

DS: what was svggen/ for?

CL: it has test files stripped from non-SVG namespace
... there were many issues with CVS revisions in the test slides
... we should make the script not generate the svggen/, and make the harness not refer to svggen/

<scribe> ACTION: Erik to get rid of svggen/ [recorded in http://www.w3.org/2008/11/20-svg-minutes.html#action06]

<trackbot> Created ACTION-2352 - Get rid of svggen/ [on Erik Dahlström - due 2008-11-27].

DS: in france, we discussed having a test suite generator
... allowing people to upload svg files and it would generate a test based on the template and that uploaded document

AG: some sort of user form you'd fill out, and fill in the fields, and for the test case content just paste in the svg into a form field

DS: and be able to upload an image

CL: why do we want to do this?

DS: it solves the problem of inconsistency in test files
... this'd be a simple additional way to make tests, and for the public to submit tests

AG: public wouldn't necessarily know the template

DS: giving them (or me) fields to fill out, makes me more inclined to make a test
... might not be the preferred way for everyone to make tests, but for some it will
... we know that these tests will conform to the template

AG: from my pov i think it's a good idea

DS: the reason you would want to base64 included images is that you won't lose external resources

AG: for some cases we'll still need external resources

CL: might make it harder to edit embedded base64 resources
... but it also helps the issue of editing an external resource and not knowing the implications for all tests that refer to it

DS: i'll mock it up and send it to the list

SVG F2F

CL: for each person who's a team contact, they get to go to one f2f meeting per year

DS: and this is retroactive, so we've already had ours

CL: so we have zero left until the middle of next year

<ChrisL4> although, if a f2f is held local to a w3c tem person they do get to go as there is no flight/hotel . So doug could have one in RTP for example or i could do one in France

CL: it is feasible for me to dial in to australia for 8 hours

AG: i wanted to know how many people are attending
... could we get the wbs form up?
... 16-20 february

DS: in the worst case chris and i can dial in

AG: i'm looking into quotes at the moment
... that's 19th jan, and erik said he'd prefer to have it later (in feb)

<scribe> ACTION: Doug to put up the wbs form for the Sydney F2F [recorded in http://www.w3.org/2008/11/20-svg-minutes.html#action07]

<trackbot> Created ACTION-2353 - Put up the wbs form for the Sydney F2F [on Doug Schepers - due 2008-11-27].

<anthony> http://www.foms-workshop.org/foms2009/pmwiki.php/Main/CFP)

DS: others can also sponsor our travel, but i doubt that would be common

Modules and the work ahead

DS: after discussions with a number of people, i think our most stable choice going forward is to assume that we are working in the way we thought we were going to be working
... that is, working on modules rather than a monolithic spec
... there are some challenges to this, but we don't want to abandon 1.2T completely, as it doesn't send good signals about maturity
... one problem is figuring out where to put stuff that is common to all modules
... i think rather than coming up with some elaborate plan where it gets pulled in from some place, we can simply coordinate on the issues (between the different module editors)

CM: yes i think we should try doing that first, before solving it technologically

CL: currently there's a blank directory that you copy to start writing a module, is that still what we should do?

DS: i've been copying one of the old modules and checking it in under the new name
... put in a new .conf file if there's not one already
... svg tiny/core need a more complicated make system than most of the modules
... since they'll likely just be single page

AG: maybe compositing would be more than one

CM: i haven't made the changes to the build script to handle single pages

DS: we can edit the master files until the scripts have been updated to handle modules

RESOLUTION: We'll stick with the current plan of having modules that work on top of 1.2T (with the goal that 1.2T + modules would have all the functionality of 1.1)

DS: we want to make it clear that SVG 1.2 Tiny is stable and future compatible regardless of what other work we do

CL: i agree

<shepazu> NH to have torkel email Doug about MAE

<shepazu> ACTION: NH to have torkel email Doug about MAE [recorded in http://www.w3.org/2008/11/20-svg-minutes.html#action08]

<trackbot> Created ACTION-2354 - Have torkel email Doug about MAE [on Niklas Hagelroth - due 2008-11-27].

- DRAFT -

SVG Working Group Teleconference

20 Nov 2008

Attendees

Contents