SVG Working Group Teleconference -- 05 Nov 2010

<trackbot> Date: 05 November 2010

<anthony> scribe: anthony

<scribe> scribeNick: anthony

<adrianba> minutes of html wg testing tf -> http://www.w3.org/2010/11/04-html-wg2-minutes.html#item04

Testing Strategies and Guidelines

AB: Above is the link to HTML WG discussion on testing
... The discussion started with a description of the process we have been following
... how people submit tests
... someone reviews them
... similar to SVG process
... discussion on what tests have been submitted so far
... currently organised by feature area
... folders for each feature
... goal of that was to avoid problems that happened in CSS where tests were
... tied to parts of the spec
... makes it difficult to change parts of the spec
... They spoke about ref tests
... and harnesses
... it turns out there wont be a single harness
... there may be several
... There was discussion about templates
... There'll be an inventory test file
... that lists all the tests
... and what the type the test is
... and any extra data required to run the tests
... that way people can build their own harness if they like
... One of the other goals was that some people had
... was the granularity of the tests
... whether to have one test per file
... or to have a test that tests a whole range of different things
... There is a balance of how many assertions you should have in a test file
... Common sense approach
... if you see a test with lots of assertions
... then it may need to be change
... it will come down to the group consensus

DS: Probably a good balance
... will be grouping tests
... according to similar features

AB: There was an upper bound of features
... that you wouldn't want to test in a single test file
... the definition of what's a feature
... is a bit vague

DS: When you're talking about scripted interfaces
... All the interfaces of an element
... might be a particular good way to go

AB: Have a number of tests of get element by class name
... would make sense to bundle those together

KK: Depends on how deep you want to go
... different APIs are more interesting
... some methods need more in depth testing

DS: Point taken
... May want to tests more variations

KK: Good start is one test for every method
... that's a good coverage

AB: The next thing people talked about was
... the difference between manual and automatic test
... If it is possible to do an automated test
... then it should be done that way

PD: Does that include static visual comparison?

KK: Had agreement that static content was visual
... that there is a page with the reference

DS: You familiar with the SVG framework

KK: No
... The motivation is that, my point of view
... the browser vendors have some information they can use there
... there is a set of canvas tests that are rendering specific
... but don't have reference tests
... but they are able to use them

AB: So then we had some discussion about hosting the tests
... on the test.w3.org
... there are some tests that require a server side element to them
... for example form submission
... you need to check what submitted is the correct thing
... and there was some discussion on how that would work

KK: For example if you're going to test cookies
... or header of HTML page
... want to change the header of cookies
... which by default is not an option

AB: One thing which my apply to SVG
... is the ability to send the information slowly

DS: Right, for resource doesn't come through
... we talked this briefly in the web apps working group
... for tests that need special server configuration
... we need to let the systems team well ahead
... we are testing these features
... if we are going to have tests which are going to run server side tests
... then they need to review that for performance and security
... W3C and the systems team will accommodate these tests
... just need to be careful
... we just need to get in early

AB: People supported the idea of sharing these server side scripts
... with other working groups
... reduces the effort required by systems team
... will avoid duplication and if you can create a test that uses existing script

KK: Because the cost is so high

AB: It was about people not having to waste time to create another test
... around that frame structure

DS: We want a cohesive web platform
... Adobe made something similar to XHR which was post XHR but before it was standardised
... that's the sort of problem we can avoid by adopting a technology

KK: If you take a bet on a bleeding edge as your tests, you may get burned down the road?

DS: I'm taking about having tests as part of the specification process
... there a some subtle things that tests will show up
... what I'm saying is since we'll be looking at tests
... we get a sanity check on the features
... we should document that
... in some obvious place
... so people can reproduce that
... maybe someone might find a flaw and help us correct it
... W3C is examining what the role of tests are in the group
... we don't want to do ISO conformance tests

KK: My point of view is that, if working group create a lot of tests
... we run into these issues
... in terms of scale
... Paul says that XQuery had 18,000 cases, which is a lot of tests
... so if working groups start to create a lot of tests
... these are problems that will come up

PD: Problems?

KK: Scale
... the SVG tests are about 4-500 you read the description
... and run it
... it's not a big deal

PD: My question is interoperability the goal or testing the goal?

DS: Our tests are simply to test the spec
... to test the spec is implementable
... W3C is looking at how we can best serve the web
... All I'm saying we don't know where we go with the tests, but it looks like we are expanding the role of tests

PD: I'm trying to figure out the size of those
... the level of coverage we want
... how much coverage
... maybe we just got to figure out where we want to go

AB: I think we need the coverage to ensure the spec has interoperability
... The one other thing we had a discussion about
... was the approval process
... this really is on point on the discussion on size and scale
... as the number of tests grows
... the burden on the working group to review the tests
... increase
... because it is more work to review the tests then create it
... and there was discussion about ways to short cut the process
... for example if all the implementations pass the test and it's worng
... then it may mean that the spec should change

DS: We've run into this in the past
... where we've found bugs in the spec
... because of the tests we were writing
... we understood the intent
... that's one of the benefits of early testing

PD: One thing about developing early is aligning tests with a set of statements in the spec

<shepazu> A Method for Writing Testable Conformance Clauses and its Applications -> http://dev.w3.org/2008/dev-ind-testing/extracting-test-assertions-pub.html

AB: That was discussed briefly in HTML and people concluded that they wouldn't try to associate specific sections of the spec
... it is often convenient to look at different parts of the spec for a test

PD: I'm talking more about having a rejection process rather than an acception process

AB: That's sort of the opposite end of the scale
... assuming that the test is right until otherwise stated was also talked about
... the problem with that model is you have a test suite of uncertain quality
... which is the purpose of the test suite
... is to test the quality of the spec
... The other thing that people said
... if you start by saying that if all implementations pass
... and spec is wrong
... what if 3 out of 4 pass
... and 4th one does what the spec says
... and the test is wrong compared to the spec
... how does that work
... and that is really where we left the discussion
... is 3 out of 4 a good metric to pass the test

PD: We've come across that before as well

KK: Even if it s approved
... there will be motivation to investigate that
... someone will check the test and spec
... the reality is the cost doesn't scale at all
... and it effects things in a bad way

PD: Was there is there any discussion about adding resources from interest groups?

KK: People say 150,000 tests, but we'll see what happens right
... it takes time to make tests
... hopefully everyone contributes tests
... I think that's just peoples guess about number of tests

DS: You could probably do a density test
... about conformance tests per page or assertion

PD: It's where they cross boundaries
... and that's where the interoperability is

DS: I thought it might worth while automating this
... and get the community to help review tests
... set up an infrastructure
... we're looking at how people can be part of W3C
... if we can crowd source in test review
... by providing incentives
... I think the percentage of people that would want to do this
... is small
... because a lot of the time
... people will look at tests for tutorials
... for people doing development they are already looking at these tests
... so in a way they are reviewing them
... if a lot of people say this test is wrong
... then we should look at it
... and there's the opposite end of the scale

PD: I think the benefit is huge
... is this goal or actual?

DS: We didn't get much interest from the browser vendors when we looked at this last year
... but my idea was to set up a portal for people to submit tests
... since we have a large community it is a way of overcoming the scaling problems
... This seems to be a good opportunity across the board

PD: So now you have built this up in SVG and I think Erik seems to like it

DB: One thing I wonder about is if you're trying to crowd source reviewing for tests
... what are you reviewing for?
... there are a number of different things you are reviewing for in tests
... this implementation is wrong, or the test is not testing things correctly
... Depending on what you're reviewing for I'm somewhat skeptical
... because it takes a lot of energy to review correctly

DS: Each test could have a thread in forum
... for people to comment
... we want to interact as low as possible to begin with
... other people who know what they are doing can teach people
... and if many people say this test is wrong
... then it would be flagged

PD: There are a number of people in the SVG community who examine the tests very well

KK: I think crowd testing works if the work your asking for is simple
... complex things will not get done
... It'll required a lot of resources

DS: Just seeing what goes on in the SVG community has lead me to believe this might work

PD: Could be pilot in the SVG Working Group

DS: All I'm saying is there are number of people in the community to probably have this run in a forum
... we might not get anything out of it
... or it might turn into something we didn't expect
... Patrick, you seemed to like the idea
... so maybe we could pilot it

ED: We could test it to see
... if there is interest

KK: What problem are you trying to solve?

DS: Get more tests possibly, more so sanity checking of the tests
... There have been times where the test has gone through the review
... and then we've looked it later and said this test is wrong

PD: John is going to help us get the transforms tests with help of Sandy and Anthony

<scribe> ACTION: Doug to Talk with Patrick and Erik about crowd sourcing test reviewing and figure out how to set it up [recorded in http://www.w3.org/2010/11/05-svg-minutes.html#action01]

<trackbot> Created ACTION-2897 - Talk with Patrick and Erik about crowd sourcing test reviewing and figure out how to set it up [on Doug Schepers - due 2010-11-12].

ED: Just curious about the strategy to take to write the tests

AB: The web apps working group is looking at using what has been established by the HTML working group

ED: I've looked at that
... and we are using the framework on two of the tests

KK: The belief in the HTML working group is you can use these are reference tests
... I think SVG is really complicated in these requirements
... with the reference tests

DS: Jonathan Watt has been looking at automating these tests as much as possible

ED: So we are already using techniques similar to ref tests in some of the tests

KK: CSS also has similar things with their tests
... they have a hard time running the test suite

PD: Do we have a way to create an automatic testing harness with Canvas

DS: Where we are right now - we are working on tests for SVG 1.1 2nd edition
... just cleaning up the spec that came out in 2001
... We have improved and included a lot of tests we had originally
... not to make work for ourselves than we can handle
... it's meant to get everyone up to speed
... and then move on
... for SVG 2
... for the modules
... we see a large benefit of using the HTML working group frame work

ED: Is there a process for putting tests there?
... is that something we need to decide to do?

DS: We would like to port our tests over that framework

AG: So where do I stick the tests that we make for Transforms?

KK: So the new tests would be made in mercurial

PD: We should get a proposal on what the categories for the spec are
... here is a functional area
... that makes a complete scenario
... and agree that these are the features that are ok

KK: If you want to do all the tests at the end you have to pick chapters
... if you're not
... you're going to have pick a feature

PD: If you were to have tests on transforms
... would you have tests on different features, like transforms on video, shapes, etc

AB: You say things like, in order to run these tests you need certain things to be implemented
... lets not try and branch out too much on the requirements

KK: If you always try to keep your dependencies as low as possible then you don't run into risks
... then build up on it later

<pdengler> RESOLUTION: Anthony continues writing CSS Transforms spec with tests, works with JohnJ and Sandro from MSFT to add more tests to the Mercurial server. In parallel, Doug, Erik and Patrick will explore sourcing resources through the community

<pdengler> ACTION: to: shepazu to start conversation with Simon Willison to understand how to kick start a wide sourcing project [recorded in http://www.w3.org/2010/11/05-svg-minutes.html#action02]

<trackbot> Sorry, couldn't find user - to

RESOLUTION: Anthony continues writing CSS Transforms spec with tests, works with JohnJ and Sandro from MSFT to add more tests to the Mercurial server. In parallel, Doug, Erik and Patrick will explore sourcing resources through the community

<pdengler> ACTION:shepazu to start conversation with Simon Willison to understand how to kick start a wide sourcing project [recorded in http://www.w3.org/2010/11/05-svg-minutes.html#action03]

<pdengler> ACTION: shepazu to start conversation with Simon Willison to understand how to kick start a wide sourcing project [recorded in http://www.w3.org/2010/11/05-svg-minutes.html#action04]

<trackbot> Created ACTION-2898 - Start conversation with Simon Willison to understand how to kick start a wide sourcing project [on Doug Schepers - due 2010-11-12].

DS: I think there is value in having people go from the spec to the tests and the tests to the spec

AB: You're right it would be useful

<shepazu> A Method for Writing Testable Conformance Clauses and its Applications -> http://dev.w3.org/2008/dev-ind-testing/extracting-test-assertions-pub.html

AB: but the maintenance would be expensive

DS: This is something that the widgets web apps group came up with this methodology
... so that you could easily mark up the spec
... so you could easily find testable assertions

AG: Done this with compositing

http://dev.w3.org/SVG/modules/compositing/master/Overview.html

DS: I wasn't suggesting that we hard code links between tests and particular parts of the spec
... just that there may be intermediary thing
... could be a manifest or index
... for tests to assertions

AB: Sure
... it would certainly be helpful
... and would be demonstrating to the director
... that you can map assertions and test cases

KK: Assertions seem like they are the bare minimum
... in some cases you need to combine them

DS: I was going to suggest we (SVG Working Group) consider adopting the assertion conformance markup for we write specs
... or something along those lines
... and how we can approve the testing frame work

KK: For SVG 2 you will move to Mercurial?

DS: Yes

<shepazu> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

DS: [gives history of integration spec]

<pdengler> ACTION: pdengler to help shepazu drive SVG "Integration" specification to editors draft [recorded in http://www.w3.org/2010/11/05-svg-minutes.html#action05]

<trackbot> Created ACTION-2899 - Help shepazu drive SVG "Integration" specification to editors draft [on Patrick Dengler - due 2010-11-12].

<ed> [break]

<pdengler> scribeNick: PDENGLER

Implementation Report

pdengler: We have the updates that were requested of us through various threads are being delivered today, including renames
... I will work with Erik to get those deliverables to him directly to make sure our renaming is done correctly

ed: Did this include a change to the implementation report page

pdengler: I am not sure it did, but I will find out shortly
... Based upon where we landed, the minimal adjustments we would want to make is a sort on test name to make it clearer to developers which features were available across browsers

ed: Do you have the full run of IE9

pdengler: No, but le me get you a date, it shouldn't take that long.

ed: I've been going through the approved harness and fixing a bunch of issues. So some of the revision numbers are not correct (fixing reference images)

pdengler: Chris is still doing a handful of WOFF fixes still.

last call issues

ed: Should we try to distirubte the actions to get them done more quickly

<ed> http://www.w3.org/Graphics/SVG/WG/track/products/24

ed: We could discuss the filter bias property. Hardly any impelmentations do anything with this feature. And there is no test right now

<ed> ISSUE-2335?

<trackbot> ISSUE-2335 -- Last Call Comment: Clarify feConvolveMatrix bias property -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2335

ed: The issue is that it is not useful the way it is specified. But no one implements this yet.

actoin: anthony to investigate support for bias in cannon impelmentation

<scribe> ACTION: anthony to investigate support for bias in cannon impelmentation [recorded in http://www.w3.org/2010/11/05-svg-minutes.html#action06]

<trackbot> Created ACTION-2900 - Investigate support for bias in cannon impelmentation [on Anthony Grasso - due 2010-11-12].

ed: Proposal is to agree with the discrepency and push the claridication/correction into SVG 2.0 depending upon Anthony's report
... (looking through LC issues)

<ed> http://www.w3.org/Graphics/SVG/WG/track/issues/2340

ed: This one is already resolved by ChrisL's check in.
... We would benefit from load balancing the remaining LC issues

<scribe> ACTION: ed to send out reminder mails to resolve issues; consider establishing delivery dates [recorded in http://www.w3.org/2010/11/05-svg-minutes.html#action07]

<trackbot> Created ACTION-2901 - Send out reminder mails to resolve issues; consider establishing delivery dates [on Erik Dahlström - due 2010-11-12].

<ed> [lunchbreak]

<anthony> scribe: anthony

<scribe> scribeNick: anthony

Establishing high level scenarios for SVG 2

PD: Are we going to be able to land a set of specs and tests
... that says this is how CSS applies to SVG
... don't really care about how it's done
... but that's a goal in mind

ED: Yes
... that's the Integration specification

PD: If our deliverable is Integration spec
... and we make any necessary updates as CSS integration is done
... then I think it is a matter of setting dates
... that we have to be aggressive about

DS: I'm curious about being realistic about things
... are there some deadlines that we have to meet?
... for example Tiny 1.2 ran to a hard deadline
... because of the JIS group wanted to standardise it
... and needed it to be done by Dec
... are there implementation hard deadlines
... I would like to know what the time lines are from the different browser vendors

PD: Willing to add extra resources if that is want is needed

DS: Testing is a big task

PD: One thing I can help do at least is help people get through specs

Time lines

PD: High level time frame is say June 2011
... stable specs for Transforms 2D and 3D (CSS/SVG)
... Filters, Gradients (lower priority), Animations, SVG Integration

JF: Our priority is 2D/3D Transforms and Gradients

PD: Anthony working on Transforms and Gradients, Doug on Integration
... myself on Animation and Erik on Filters

DS: I am interested in animation

AG: We'll also have help from other people in other groups as well
... Dino, Simon Frazer

DS: I would also really like to have Adobe in on the conversations about Animation as well
... and I'm concerned about is having the authoring tools

AG: It would be good to have Alex D in the discussions as well

DS: And Vincent Hardy
... I want to have some concept of state in animation
... If I say have a button and I would like to have two different things happen depending on if it is on or off
... Just some simple concept of state

<pdengler> http://www.w3.org/TR/2009/WD-SVGCompositing-20090430/

AG: SVG Compositing is ready to go
... so may as well do it as well

DS: I'm really concerned with the DOM

ED: Me too
... it's on my top list

DS: The DOM is very inefficient

ED: I'm interested in the simplifications
... to make it easier to use

AG: Similar to uDOM?

ED: More so about simplifying base value

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API

DS: I don't want to bother with insertAt
... like if you don't give it anything it just appends it

<pdengler> http://www.w3.org/Graphics/SVG/WG/wiki/images/6/64/SVGCSSTPAC.pdf

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

PD: On page 6
... there's the puts

ED: One of the things suggested already

PD: Only trick is that it returns a string when you query the base value
... it returns it a string
... the only issue is if you use the set-er you have to change the unit type
... so if I set the string with rect = px then you have to make it to be that

ED: Depending on what you get as the input
... there is a function like that
... for me it's more about aligning with the DOM core
... it is easy and left the old ones as aliases
... we had to add more code to do the array syntax

PD: I would love to have this as something we solve

DS: We should remember we have Cameron in the group
... and he is good with the IDL stuff

PD: I would like to add the DOM fixes to that urgent push

AG: Could probably get Cameron to do that if he's interested

DS: I'd be interested as well

PD: What's the work?

ED: Not much work I think

PD: Whatever work needs to be done or think needs to be done
... should ask him if he thinks it could be done
... I'm thinking about if people can code against the HTML DOM will be able to code against the SVG DOM

<Hyeonsoo> las

<scribe> ACTION: Doug to Coordinate with Cameron to scope SVG DOM simplifications and establish a spec with a delivery date [recorded in http://www.w3.org/2010/11/05-svg-minutes.html#action08]

<trackbot> Created ACTION-2902 - Coordinate with Cameron to scope SVG DOM simplifications and establish a spec with a delivery date [on Doug Schepers - due 2010-11-12].

ED: Only concern I guess is we will be done with 1.1
... and we will have to add the dates to the charter
... How long does the charter have to go?

DS: 2 years

<tbah> How does one call in?

coons patches / gradients

<tbah> http://tavmjong.free.fr/SVG/MESH/Mesh.html

TB: Link to a webpace I've prepared
... The motivation method is they are useful to producing vector art
... and we also get discussions similar to this on the mailing list
... there are 4 types
... gradients I could find
... they are listed
... [goes through different gradient types in paper]
... we've been talking through mostly coons patch gradients
... one thing you can do with coons patch gradients
... is emulate other gradients
... There's a four point coons patch gradient
... couldn't find anywhere this is used thought
... One thing I noticed looking on the web, is the patches are always done with a rectangular grid
... One problem is you can fold it on top of itself
... and so if you have a sharp turn in curve and it has transparency
... could be problems
... so putting this in SVG is defining how you would render this
... each patch shares two colours and one bezier path
... you can zig-zag your patches along
... existing SVG gradients there are linear and radial
... and they have stops
... which doesn't really fit with coons patches
... because the colours are defined in the corners
... The mesh is defining the shape of the object

CL: You could use the shape as a clipping path

TB: You could do that
... but they are not used like that in the wild
... you're interested in taking the grid and deforming it to fit with a shape
... essentially it already is being self clipped
... There is one case where you would want to fill it an object
... and that's when you would do that with conical gradients
... You set up a rectangular grid
... It seems like a good idea to set up the gradient like a grid
... Illustrator seems to do this as well
... So go along the rows
... which define the sides and colours
... in the corners
... The coon patches are defined in terms of bezier curves
... Could use other paths
... and use approximations to bezier curves
... I've listed there one possible syntax
... Divide and conquer method could be used to render it
... There is an experimental Cairo implementation that implements this
... using Forward-rasterize
... Jasper replied back with some comments
... he gave me an example
... where you have a gradient
... and you map those using a transform function
... to a mesh gradient

CL: On the top left patch
... you have to have 3 points on subsequent squares
... just wondering how this would work if you animated it
... or edited it through script

DS: It almost seems there is some relationship between tiling and super paths

TB: I'm not sure it's something you would animate
... It's quite a bit a work, and why you'd want to animate it

DS: If you gave this to David Daley he'd animate it
... because he looks for cool stuff
... If someone had a particular goal in mind
... We do have consider animation
... One concern I have is with conflating the paint sever with the mechanices
... of the shapes
... the actual geometry of the shape
... One thing I don't like about Diffusion Curves
... if you look at the lines that are being defined
... there's no shape you are clicking on

s/mechanices/mechanics/

TB: You do have the outer bezier curve defining the shape

AG: I think any gradient extensions we add should be a paint server
... otherwise you break the model

CL: I can imagine that ball effect you have there
... with the lighting
... that you'd want to animate that

TB: Getting this drawn is a lot time by hand
... I can understand what you want to do and it would be great if you could do that
... most people are not going to do these things by hand
... I wanted to do something more complicated than sphere
... just didn't have more time

DS: I think it's great you spent the time in putting this together
... The first image I looked at made me think they are limited

TB: I wasn't able to do complicated drawings
... but you can find complicated examples of their usage on the web

<tbah> http://www.khulsey.com/adobe_illustrator_gradient_mesh.html

CL: I means that the authoring tool is needed to do this
... because if you pick up a point
... you'll need the tool to move other points

TB: You could animate it
... but it is not trivial

<ChrisL> http://en.wikipedia.org/wiki/File:Phong-shading-sample.jpg

CL: Did you see anyone using phong shading meshes instead
... If you follow the link there
... you'll see the same mesh using two different methods

<ChrisL> http://en.wikipedia.org/wiki/Phong_shading

CL: the phong shading is much smother
... because you are interpolating the normals
... the reason that came up and we tried using tri-mesh
... using Gourand shading
... and it didn't look smooth

s/smother/smoother/

scribe: It's used a lot in 3D (Gourand) shading
... as a step up from wire frame
... then you apply phong shading and it looks real
... which means there is hardware support for both
... The coons patches are cool but they are all done in an authoring tool
... and then rendered in software

TB: A triangle mesh you could animate each point

CL: The Triangle mesh proposal I made in terms of animation was easy to animate

<ChrisL> coons patches are on the cairo to-do list

TB: So animating triangles is kind of a problem

<ChrisL> http://cairographics.org/todo/

CL: I see Coons patches are on the Cairo to-do list

TB: Yes
... it's experimental at the moment
... and there are a couple of examples they have there
... might not be the best implementation
... but there is at least a sample

ED: From analysing this, did you look at what PDF are doing with this?

TB: Yes, PDF and postscript are doing something exactly the same
... and you can add on a new patch one at a time
... you can zig-zag them back and forth

ED: Well where do we want to go with this?

CL: The question is it supported by libraries
... and does it give us what we want
... My concern is it requires an authoring tools as well

<jun> other method - http://graphics.cs.uiuc.edu/~tianxia/pdfs/imgvect_preprint.pdf

TB: Animations aside, using this method you can produce life like images

AG: There are other methods out there to produce life like images as well
... such as Diffusion Curves

TB: Looks like they are doing triangle beziers on the side

AG: I think it is worth having some use case and requirements

JF: We should study available methods
... some methods can be used on a wide range of images
... and some methods can be applied to a particular type of image
... so we need to know the requirement

<ChrisL> trackbot, status

<scribe> ACTION: Tavmjong to Work with Tab Atkins on gradient extensions use case and requirements [recorded in http://www.w3.org/2010/11/05-svg-minutes.html#action09]

<trackbot> Created ACTION-2903 - Work with Tab Atkins on gradient extensions use case and requirements [on Tavmjong Bah - due 2010-11-12].

ED: Thanks Tav for doing the work

<ChrisL> scribe: ChrisL

retrospective on 2010

cl: problem was shrinking below critical mass, too few members to do the work
... and also not knowing that going to LC means we had to go to CR and PR, not PER
... lots of work n 1.1SE test suite, much better, but was this the best time to do it

ds: inevitable the way it happened, microsoft was not prepared to be takling 2 for excample, so focus was on 1.1
... now we have a broad interop o 1.1 features, so optimal time to move to svg 2
... we have buy-in now

cl: great to have cam back

erik: yes, you can see commits from cam as soon as he came back

cl: spoke to suresh about wildfox joining svg wg

(discussion on assorted svg-related hiring opportunities we notice)

ds: moving to one telcon a week, proposed by heycam
... but need to be more active on the list

Resolved: one telcon a week on Thursday

ag: happy to be an hour earlier, may be better for patrick too

erik, chris: better for us

ag: ok for heycam?
... better in nz

proposed: one hour earlier for svg

<scribe> ACTION: erik to mail wg proposing new time [recorded in http://www.w3.org/2010/11/05-svg-minutes.html#action10]

<trackbot> Created ACTION-2904 - Mail wg proposing new time [on Erik Dahlström - due 2010-11-12].

(discussion on svg meeting in tokyo co-located with css wg meeting in June 2011)

ed: need to get milestone dates for the next charter, so we need to decide on priorities

ds: will put those dates in the charter

ed: don't want svg 2 to be a 1.3 with minimal changes

ds: animation will be better

ed: great, but nt really a new feature
... the name has already stuck

ag: will have new stuff in it

ed: don't mind if there are many new modules and svg2 is a good feature set, moving modules ahead at their own page
... at soe point we still need to group the together

ag: though we said a year afte rthat, so June 2012

s/soe/some/

<anthony> s/afte rthat/after that/

cl: modules move based on their effort, degree of developer interest, and trest suite status

s/what i typed/what I meant/

ds: are we going to include modules byreference or by inclusion?

cl: joint specs, so we clearly need to do it by reference

(discussion on how best to reftest features like filters; how to avoid platform differences in text antialiasing etc)

action chris to add Helder missed issues to LC tracker

<trackbot> Created ACTION-2905 - Add Helder missed issues to LC tracker [on Chris Lilley - due 2010-11-12].

http://lists.w3.org/Archives/Public/www-svg/2010Aug/0009.html

http://lists.w3.org/Archives/Public/www-svg/2010Aug/0014.html

http://lists.w3.org/Archives/Public/www-svg/2010Aug/0015.html

first one is about changes. but next publication will list changes since last (LC) publication

we need a good and complete list of changes between the last /TR publication and the next one

<scribe> ACTION: chris to respond to Helger to explain that changes appendix is relative to last published version [recorded in http://www.w3.org/2010/11/05-svg-minutes.html#action11]

<trackbot> Created ACTION-2906 - Respond to Helger to explain that changes appendix is relative to last published version [on Chris Lilley - due 2010-11-12].

not clear how to edit in place the first edition to give dated links

<ed> http://www.w3.org/TR/2003/REC-SVG11-20030114/ecmascript-binding.html

<scribe> ACTION: chris to talk to comm team anout editing in place svg 1.1 first edition to absolutize some undated links to ecmascript appendix [recorded in http://www.w3.org/2010/11/05-svg-minutes.html#action12]

<trackbot> Created ACTION-2907 - Talk to comm team anout editing in place svg 1.1 first edition to absolutize some undated links to ecmascript appendix [on Chris Lilley - due 2010-11-12].

his third comment is a test case typo. not a lc issue. we fix it live in the meeting

adjourned

- DRAFT -

SVG Working Group Teleconference

05 Nov 2010

Attendees

Contents