SV_MEETING_TITLE -- 28 Oct 2010

<pdengler> http://player.microsoftpdc.com/Session/6b113af7-ba3e-44ae-bf8c-1f394029cc18

<jwatt> Zakim: IPcaller is me

<jwatt> Zakim: [IPcaller] is me

<ed> scribeNick: ed

SVG 1.1 2nd Edition Test Suite Analysis

<scribe> chair: heycam

PD: good thread on the mailinglist

CM: maybe i've been out of the loop for a bit

CL: the naming convention is what we've been used to date, just the section in the spec
... what's wrong with that?

PD: don't disagree with that... the problem is if ppl look at these tests and try to judge if browsers support svg, because of the file naming
... my solution is: rename the tests... or if that's a problem, ...[scribe missed]
... many ppl are going to see these tests

CL: if the tests are testing things that aren't in the section in the spec that the filenaming suggests
... some tests use animation, but they're not particularly testing animation, but other things

PD: i don't want devs to look at e.g struct-* and IE or FF fails
... testing animating colors and gradient, just letting people understand the test uses e.g colors AND animations AND fonts

CM: if people are making that jump, if some tests fail the whole spec is not interoperable...

PD: a fourth suggestion is to make the implementation report categorize the tests

DS: is anyone suggesting something else?

CL: we're missing a category for combinations of features

<pdengler> >>> The SVG Working Group could modify the conformance template to re-categorize these tests into their appropriate area.

PD: we're close, i don't want to hold back process
... the modules browsers get to last should be categorized, like fonts, or filters, or animation...
... there should be exceptions, to not confuse developers

CL: some tests uses svgfonts because they're helpful for knowing exact metrics in advance
... some tests will still pass even if svgfonts are not supported
... tried to convert svg -> woff and adding that to one test
... trying to figure out how to do that
... we could add woff fallback fonts in css

PD: so for the compositing test svgfonts are not really required
... concerned that woff isn't yet a standard
... don't understand the pushback on renaming tests

CL: we decided already that woff fonts will be mandated by SVG2
... so i'm not too concerned about those

DS: we need reliable fonts to give the expected appareance on particular tests
... how best to achieve that passing criteria / that effect?

CL: we've already done that for one of the tests, using ahem
... and we have an svg ahem
... both look the same
... both provide the same end result

PD: if other vendors agree adding more fallback fonts sounds good

DS: don't think this is a point of contention

PD: would like us to address this concern this for SMIL

CM: some tests use smil for mechanical reasons, just for generating events at particular times
... [missed] so you basically want the renaming to happen?

CL: renaming the tests is probably easier than recategorizing the tests

DS: there's a bit of work
... to do this
... the tests are approved, but going through substituting the names...
... if MS has resources available to help with that that would be good

PD: sure
... CL was going to help to add WOFF to some tests

DS: if you are renaming tests, some tests have dependencies
... maybe some tests need to be rewritten
... maybe to remove use of some particular feature

PD: i'll take each test that depends on smil, and split out the smil stuff

CL: one test was testing unsuspendRedraw, that could probably be rewritten as a script test

PD: i'll do what you want

CM: renaming the test first, making changes later

DS: have we studied what level of support is required for passing a test?

CL: we tried, but then we started to assume that more and more things were there

DS: agree with patrick that filters animation and fonts are heavyduty
... so putting them in a higher category seems reasonable

ED: i disagree, all the mobile implementations did animations and fonts, filters sure, those are harder (and harder still to do well on old mobile platforms)

CM: we could have levels of test, one simple, one hard, or several levels of passing (?)

PD: tests that use smil and something else we will propose a solution

DS: renaming the tests is my proposal
... don't want tests removed, rather have substitute tests added

PD: pulling out non-essential smil

DS: creating alternate tests, anything that uses animation should be named something animation
... this topic is becoming a permathread
... my proposal is that if any test uses animation, the test should be named something-animation
... in some way it's testing animation, regardless if that's the main point of the test

ED: i like being able to quickly find tests based on a section in the spec
... keeping the naming scheme, but adding a suffix to indicate if it's using FOOBAR maybe could be ok...
... don't want most tests to start with animate-*

<pdengler> pdengler: Rename all tests that have SMIL with a prefix of animate-elem-

<pdengler> pdengler: For those tests that have merely a mechanical (non SMIL focussed test), in addition to the animate-elem rename, let's create a test without the SMIL elements

ED: I disagree with the "Rename all tests that have SMIL with a prefix of animate-elem-"

DS: i don't follow
... MS thinks that tests should only test one single thing

AG: we could use the tiny12, and add a numerical series like 40x

<pdengler> pdengler: MS does not think that a test should only test a signle thing as evidence by the tests we have submitted, that's not the poitn

<heycam> ScribeNick: heycam

DS: is it ok with you if we, for tests that have purely mechanical uses of animation, that we substitute new tests for those tests, keeping the existing tests in the test suite, but essentially marking them as having something to do with animation?

ED: that part is fine with me
... i agree we should have tests not using SMIL as well
... there's more than one way of doing something, so why not test all of them

DS: i agree there, so i'm not sure where the problem is

ED: my problem is mostly with the prefix. i wouldn't like the test suite to have animate-elem-

AG: that's why i made my suggestion [of 400-series tests]

DS: how about combo-?

AG: that'd break the test suite generation scripts

DS: can't we fix the tests?

AG: there's no chapter "combo-"

CL: in that case don't give a link to the spec

DS: or we all call them animate-elem- because they do have something to do with animation, and the scripts won't break

ED: there are other tests that are testing other features as well, you have to rely on some things at some points

DS: if you just prefix it with anim-elem something, and it also has the other names in it, will it break the scripts?
... here's the thing the tests are testing, and it also uses animation

AG: the scripts are fixed to a certain number of dashes in the name, would have to go back to the scripts

ED: maybe renaming the tests is not the best way to go about it. maybe changing the template to identify what's relied on.

DS: that sounds like a lot more work

ED: what would you rename it to then? who decides which feature it should be listed as, how long can filenames be?

DS: so we have one vendor that has a problem with three features, and that's it. i don't see this being a situation where we're going to get out of control...

ED: i think you are understating how much work it would be

<ed> ED: it'd be really easy to write a script to pull out what elements a particular test uses, that could be a reasonable indicator

DS: what is your proposed solution?
... another one is to change these 30 tests completely, get rid of the ones that have smil in them, and then review and approve these 30 tests, which we'll have to do anyway, and dump the old ones or put them as unapproved or something
... it's a solution i like less, then we don't have these combinatorial tests that we would otherwise be getting for free
... i think this is the main reason i object originally about having the file name being the identity of the test

CM: patrick you were saying that it's the implementaiton report you're worrying about rahter than the test names, right?

PD: yes
... my belief is that the impl report should easily reflect the features that folks can depend on. i realise that the tests are dense. i believe that people depend on text, and masking, gradients.... and firefox and we won't pass these. i don't care.
... i jsut want the impl report, at a glance, that it's easy to see that they don't pass because it's filters, or animation, that is used

<ed> http://dev.w3.org/SVG/profiles/1.1F2/errata/implementation-report.html

http://www.w3.org/mid/4A2DB3AE4504E944AF122BBFBA7FBA1F54D8FB55@TK5EX14MBXC114.r

edmond.corp.microsoft.com

<shepazu> http://www.w3.org/mid/4A2DB3AE4504E944AF122BBFBA7FBA1F54D8FB55@TK5EX14MBXC114.redmond.corp.microsoft.com

<shepazu> http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/0075.html

<ed> http://dev.w3.org/SVG/profiles/1.1F2/test/svg/paths-dom-02-f.svg

http://www.w3.org/mid/20101028035114.GO10034@wok.mcc.id.au

ED: i will look at that list of animation tests and get back to you, but i think it'll be ok
... it's just the ones targetting the animation report?

PD: yes

[we talked about the fonts one getting woff font fallback ones]

PD: but if we can't do the woff thing, we might have to look at prefixing these too. but the woff solution would be perfect.

<scribe> ACTION: Chris look at patd's font tests to add woff fallback [recorded in http://www.w3.org/2010/10/28-svg-minutes.html#action01]

<trackbot> Created ACTION-2887 - Look at patd's font tests to add woff fallback [on Chris Lilley - due 2010-11-04].

<scribe> ACTION: Erik to look at the animate tests in patd's email for renaming [recorded in http://www.w3.org/2010/10/28-svg-minutes.html#action02]

<trackbot> Created ACTION-2888 - Look at the animate tests in patd's email for renaming [on Erik Dahlström - due 2010-11-04].

auckland f2f

JW: looking through the dates people sent me, seems like the first 3 weeks in march are the best
... i'd suggest the first week, which starts on monday 28th feb, and ends on friday 4th march

CL: sounds good to me

DS: i'll just check if i have any conflicts

JW: this is probably one of the only opportunity to meet the people who are working on svg for mozilla, if that helps get you here

DS: those dates work for me

JW: pat do those dates matter to you?

PD: no it won't change anything

JW: i'll send an email about it starting on the 28th feb

TPAC

CL: i have a few constraints. thursday afternoon we've got fx tf thing.
... other constraint is that svg and webfonts are meeting on the same day
... so i'll have to split my time between the 2 groups

DS: friday?

CL: i'm probably doing mornings and afternoons. so mornings in web fonts and afternoons in svg.

CM: agenda link?

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Tpac2010_Agenda

ED: was hoping tav would have something with gradients research

CL: we haven't really got submitted impl reports, so we can't really see how close we are to being done
... i'd really hoped we could know we're deeply in trouble or know we're almost right
... i want 1.1 2ed out the door and behind us

CM: that's just relying on people running the tests, right?

CL: yes, but we still haven't got a finalised set of tests
... as erik said recently we can start, we just update the impl report as things change

PD: i like the idea of getting prepped our css discussion on thursday, i think we could break that out
... i sent a document to the fx mailing list that i'm not seeing yet

ED: do people need to dial in to tpac?

DS: maybe, timing might not work out for most people

CL: i asked for a phone

PD: i'm going to present on the html.next panel at tpac

<shepazu> http://www.w3.org/2010/webevents/

<anthony> trackbot, end telcon

- DRAFT -

SV_MEETING_TITLE

28 Oct 2010

Attendees

Contents

SVG 1.1 2nd Edition Test Suite Analysis

auckland f2f

TPAC

Summary of Action Items

Scribe.perl diagnostic output