20:00:36 RRSAgent has joined #svg 20:00:36 logging to http://www.w3.org/2011/05/26-svg-irc 20:00:38 RRSAgent, make logs public 20:00:38 Zakim has joined #svg 20:00:40 Zakim, this will be GA_SVGWG 20:00:40 ok, trackbot, I see GA_SVGWG(SVG1)4:00PM already started 20:00:41 Meeting: SVG Working Group Teleconference 20:00:41 Date: 26 May 2011 20:01:41 +??P4 20:01:43 Zakim, ??P4 is me 20:01:43 +heycam; got it 20:01:46 Zakim, who is on the call? 20:01:46 On the phone I see ??P1, heycam 20:02:18 + +1.408.536.aaaa 20:02:32 vhardy has joined #svg 20:02:33 +Doug_Schepers 20:02:37 Zakim, ??P1 is me 20:02:37 +jwatt; got it 20:02:38 +rik 20:03:39 +tbah 20:04:08 +??P11 20:04:16 Zakim, ??P11 is me 20:04:16 +ed; got it 20:04:53 Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/0122.html 20:06:01 Zakim, who's here? 20:06:01 On the phone I see jwatt, heycam, +1.408.536.aaaa, Doug_Schepers, rik, tbah, ed 20:06:03 On IRC I see vhardy, Zakim, RRSAgent, tbah, cabanier, jwatt, shepazu, ed, trackbot, heycam 20:06:41 ScribeNick: vhardy 20:07:03 Topic: SVG2 features and approach 20:07:25 That could work I think. Can we talk over email? 20:08:05 ed: how do we find which features people think are the most important ones? 20:08:32 heycam: we discussed it previously. 20:08:51 heycam: I think we agreed to use a tool to do the poll. 20:09:04 shepazu: I am not comfortable using an external, non-w3c tool. 20:09:12 shepazu: have you heard about the community groups? 20:09:38 shepazu: W3C has community groups and there will be an infrastructure for forums and polling. This should help collect information. 20:09:45 shepazu: this is not urgent, right? 20:10:31 vhardy: some initial focus would help our efforts. 20:10:49 shepazu: I think we can wait a couple months. Does that make sense? Are we going to lose momentum? 20:11:06 heycam: there is enough things to work on in the next two months. 20:11:20 heycam: but people are mentioning things on the list right now. 20:11:28 shepazu: we can still collect it? 20:11:31 vhardy: how? 20:11:58 shepazu: it has been a pretty short thread so far, except for contributions from Dr. Olaf and David Dailly. 20:12:47 heycam: should we take the topics from the mailing list and put it on the wiki? 20:12:53 shepazu/vhardy: yes, good idea. 20:13:01 vhardy: who does that? 20:13:18 heycam: we need to chose somebody. 20:13:41 shepazu: I think I should normally do that, but right now, I am too busy at the moment. 20:13:59 vhardy: when do we need this by? 20:14:11 shepazu: I do no think this will change in the next two months. 20:14:35 heycam: I think we still should collect the threads right now. 20:15:29 shepazu: there was some talk about having no new features. 20:15:37 heycam: there will likely be some new features. 20:15:52 shepazu: implementors can still implement or not implement certain features. 20:16:10 shepazu: if two implementors want to do a feature, there is a pretty good rational for doing it. 20:16:35 shepazu: this discussion is speculative at this point. But we will be driven by implementation, because of the CR criteria. 20:16:56 heycam: we do not want to specify a whole bunch of features with no implementation input. 20:17:31 ACTION: heycam to collect initial email feedback on SVG 2.0 features the group should take on into a Wiki. 20:17:32 Created ACTION-3045 - Collect initial email feedback on SVG 2.0 features the group should take on into a Wiki. [on Cameron McCormack - due 2011-06-02]. 20:19:01 ACTION: shepazu to send emails to the stakeholder mailing lists (www-svg & svg Yahoo developers) lists to solicit feedback on the high priority features the group should take on, preferably with use cases and requirements. 20:19:01 Created ACTION-3046 - Send emails to the stakeholder mailing lists (www-svg & svg Yahoo developers) lists to solicit feedback on the high priority features the group should take on, preferably with use cases and requirements. [on Doug Schepers - due 2011-06-02]. 20:19:32 ed: I wanted to talk about the SVG 2 process. jwatt wrote a wiki page on that. 20:19:37 vhardy: link? 20:20:30 s/That could work I think. Can we talk over email?// 20:20:33 hmm... was it this one? http://www.w3.org/Graphics/SVG/WG/wiki/SVG2/Specification_authoring_guide 20:21:17 http://www.w3.org/mid/4D8AC692.8030205@jwatt.org 20:21:50 heycam: we had two different ideas. One is to start from a blank slate and rewrite as we go. 20:22:08 heycam: and not copy the original SVG text. 20:22:33 heycam: the other method is to start off from the SVG 1.1 text, mark all of it as unreviewed. And then migrate as we go. 20:22:45 shepazu: that is a fair summary. 20:22:56 heycam: there were various points. 20:23:24 heycam: but the starting point is the biggest thing to resolve. 20:23:52 shepazu: my approach is to start from scratch and make sure we get everything right? 20:24:24 shepazu: how do we make sure we get everything we need in the spec? There were discussions about this. There are two factors that weigh for my argument. 20:25:10 shepazu: one, we have established in previous telecons, we are not going to fold-in features that we now share with CSS. We will reference them, e.g., "a conforming SVG UA implements filters". This will knock out at least 3 chapters. 20:26:11 shepazu: another argument is that we have such legacy material in the spec, and it is so hard to fact check every bit, that not starting from a black slate will be complex very rapidly. 20:26:31 shepazu: with SVG 2, we should be freeer about how we can bring things in. 20:27:06 shepazu: this is the cruz of my argument, I think it is simpler to start from scratch. I did that approach for most of the DOM Level 3 spec. 20:28:13 shepazu: the editors of the DOM Core new spec. have been able to incorporate the new DOM Level 3 event spec. much more quickly compared to what I went through. 20:28:27 shepazu: it will also be easier to unify our language. 20:28:46 heycam: I have some comments, but may be jwatt can comment first? 20:28:51 heycam: jwatt? 20:30:07 jwatt: I just want to see what is changing as we go along, so this is why I would like to start from the existing spec., to see a kind of linear progression. 20:30:29 jwatt: starting from scratch, we will see incompatibilities like between SVG Tiny and SVG Full. 20:30:58 q+ 20:31:07 jwatt: the idea of trying to keep track of what is kept from the old spec. seems very complex to me. 20:32:04 vhardy: could both of you elaborate on the problems you ran into before? 20:32:28 shepazu: one of the problems with DOM 3 Events was keeping track of what I had or had not changed. This was tedious. 20:32:31 -rik 20:32:40 shepazu: may be I was not methodical enough. 20:33:37 shepazu: If I had to do it again, I would mark all the spec. as unreviewed and then mark it as I go. 20:34:03 shepazu: for SVG 1.2, did it help to have existing text in place? 20:34:38 shepazu: SVG Tiny 1.2 was SVG 1.1 cleaned up with some features added. I don't think it was a success. It was hard to find what had or had not been edited. 20:36:09 heycam: I feel that starting with the existing text does not just mean we would review paragraphs one by one. We may rewrite parts of the text. But we would have to methodically mark the text so that we make sure that any removed text gets an equivalent new text. We should also make sure everything happens under version control. 20:36:44 vhardy: our specs. are under version control. Are you talking about a better use of version control? 20:36:55 heycam: with Mercurial, we would have better version control support. 20:38:16 heycam: may be we should keep a version of the old spec. and pull things in from the new document. 20:38:29 jwatt: to be able to compare with the SVG 1.1 spec. is really critical. 20:38:46 shepazu: we can just diff two different documents. 20:39:02 heycam: that is difficult because the new document can be structured completely differently. 20:39:37 jwatt: diffing two documents shows you the differences between documents and they are compacted in a single item. 20:39:48 jwatt: source control tells you what happens in a given commit. 20:40:06 shepazu: it takes discipline to track all this. 20:40:22 jwatt: changes must be done in logical order. 20:40:35 jwatt: for example, a change where we update the way links are done in the spec. 20:41:17 shepazu: to me, it comes down to having to read both the old and new document and check that there are no contradictions. 20:41:43 shepazu: the SVG 1.1 spec. is confusingly organized, some pieces are scattered. e.g., pointer-events 20:42:21 jwatt: I have not problem with a commit that butchers pointer-events and replaces it with a new text. 20:43:02 jwatt: I think we really need to be able to track individual changes to the spec. 20:43:23 jwatt: my hope is that at the end of the process, we have fewer incompatibilities between the new spec. and the old one. 20:44:04 shepazu: I understand what you say, but I do not think it will bear out. It will be so much more effort to work around existing passages of text instead of writing new text. 20:44:52 shepazu: I think the argument will come down to a few people understanding fully any particular issue, understand what SVG 1.1 says and then rewrite for SVG 1.2 20:45:23 shepazu: I do not think that incremental changes are the way SVG 1.2 will come about. 20:45:57 shepazu: I think looking at the diff would not be the way to do it. The process will be to compare idea to idea, not line to line. 20:46:12 jwatt: it does not need to be line to line. It needs to be incremental. 20:46:18 -tbah 20:46:38 shepazu: I think we are not going to agree. We do not necessarily need to pick one approach. 20:46:45 +tbah 20:46:52 shepazu: we may start from different starting points and see what works best. 20:47:24 shepazu: having a lot of experience working with existing documents, including SVG 1.1 and SVG 1.2 tiny, I know it does not work. 20:47:48 shepazu: I am personally not willing to work that way. 20:48:01 shepazu: I do not want to mash bits and pieces. 20:48:23 shepazu: if the rest of the group wants to work that way, that is fine. 20:49:17 shepazu: if we start from the existing spec., it is going to be really hard to do anything. 20:49:39 jwatt: I am afraid that we will lose things if we start from a clean slate. 20:49:57 jwatt: like with new software just replacing old one. 20:50:26 shepazu: there are limits to that analogy. But it is true that with software you may lose functionality. 20:51:12 shepazu: specs are not software. If there is wording that is not well understood, then it should not be in the spec: how do we test it? how do we explain it? 20:51:48 jwatt: as an implementor, the spec. is a ton of things that are quite subtly connected and it is just by implementing that you realize the subtleties. 20:52:22 shepazu: I do not want to force my way down everybody's throat. 20:52:38 shepazu: if the group wants to start from 1.1, they it should. 20:52:56 shepazu: for the parts I edit, I would prefer to start from scratch. 20:53:55 heycam: starting from 1.1 means that you would have all the document styled away. When you start on a new section, you do not necessarily have to start from the previous version. You can edit or replace. 20:54:24 heycam: the difference may not be as big as we think. But at least you see what is being added/changed. 20:54:38 ed: that makes sense. There will be other types of changes too. 20:55:03 ed: in the end, we will still have to look at both specs. 20:55:19 shepazu: yes, people will have to review two specs. 20:55:25 both, might mean all three, or more specs fwiw 20:55:30 shepazu: there may be more dramatic changes. 20:57:24 heycam: most of the time, when it comes to take an old paragraph from the spec., you would not be doing minor changes but writing things from scratch. But having the old text in the file, you still have the connection to the old text. But you are not burdened by the old text. 20:57:51 shepazu: I do not understand how it is important to delete the old text. 20:58:27 jwatt: it helps for sections where the changes are not too dramatic. 20:58:54 jwatt: and it does not stop the complete rewrites for the sections/chapters that need it. 20:59:15 shepazu: I am not sure which sections should remain. I think we should rewrite all sections of the spec. 20:59:39 shepazu: why don't you start as you suggest? 20:59:49 jwatt: I would like to hear other people's opinion. 21:00:16 heycam: the argument to track the changes we make is convincing to me so that we know how the spec. changes. 21:00:44 heycam: on the other hand, I am not sure how much will be completely rewritten v.s., edited. 21:01:28 heycam: even if all the text needs to be rewritten, it still has value to see how the spec. is progressing. 21:02:18 shepazu: from an external review perspective, I think it sends very different messages. If we keep the old text, reviews are going to be difficult. 21:02:27 shepazu: I think this is adding overhead. 21:02:37 heycam: I think there will be overhead but not much. 21:02:59 heycam: I think we could try it and then see that, if the overhead is too much, then we will adapt our process. 21:03:20 Scribe: Cameron 21:03:21 ScribeNick: heycam 21:03:35 VH: starting from scratch sounds compelling, btu the volume of work is kind of staggering 21:03:47 ... it's a huge spec, if we're talking abotu rewriting every paragraph in the spec 21:03:58 ... my gut feel is that I'm more comfortable with evolving and fixing 21:04:06 ... having implementing large portions of the spec, I don't have that many problems with it 21:04:15 ... like anything it can be improved, but I don't think everything should be rewritten 21:04:21 ... I do find there are portions that are well written 21:04:25 ... it's also a difficult exercise 21:04:36 ... that it has problem therefore we have to throw everything away concerns me a bit 21:04:44 ... I also share the concern about seeing things evolve 21:04:52 ... starting from scratch it's hard to see how you've evolved 21:05:00 ... I agree in the end you'll need to compare two specs 21:05:06 ... but the evolution will help you 21:05:17 DS: I think there are sections we won't rewrite in the end 21:05:27 ... neither approach says "oh we can't have any text from the old spec" 21:05:47 ... each one says we're going to review everything we need as we go 21:06:21 ... like I said, I don't think I will persuade you all, so I'm not going to pursue it 21:06:34 VH: a followup, who's committed to being an editor of the spec? 21:06:40 ... I think the editors should have a lot of weight in the process 21:06:44 ... since they're the ones doing the work 21:06:51 ... the process should serve and help them, and not be imposed on them 21:07:09 ... as much as we work with consensus, people who are doing the day to day work should have more weight 21:07:24 JW: SVG has had a much more open policy of everyone editing the spec 21:07:29 ... some people do more work than others, obviously 21:07:36 DS: in reality not everybody edits 21:07:45 ... it's a nice idea, but in reality most people don't edit, or edit very little 21:07:58 JW: once we're in mercurial I'll edit a lot more 21:08:14 ED: are we getting closer to deciding what to do here? 21:08:32 DS: since I'm in the dissenting voice, I'll retract my suggestion 21:08:49 konaya has joined #svg 21:08:58 ED: there's some overhead in removing the old text, but probably not that much 21:09:03 ... but I'm fine with starting with the old spec and removing parts 21:09:24 DS: if we do it this way, I would really really ask that we not have the old text visible 21:09:36 Scribe: Vincent 21:09:38 ScribeNick: vhardy 21:09:49 shepazu: we should indicate to reviewers which parts people should be looked at. 21:10:18 shepazu: even having an editor draft with things marked as "do not review", I still get reviews on that part. 21:10:35 ed: then we will need invisible text (commented out or invisible). 21:11:17 shepazu: I am worried because the spec. is not organized in a good way and starting from the existing spec. may be difficult. 21:11:41 heycam: at some point, I suggested to put the whole spec. in a single document. 21:11:55 heycam: this was in part to give more flexibility to the spec. organization. 21:12:19 ed: we reached some kind of consensus on how to proceed. We need an action on someone to do the initial commit. 21:12:41 ACTION: jwatt to do initial SVG 2.0 commit into Mercurial. 21:12:41 Created ACTION-3047 - Do initial SVG 2.0 commit into Mercurial. [on Jonathan Watt - due 2011-06-02]. 21:13:44 RESOLUTION: The group decided to start the SVG 2.0 from the SVG 1.1 2nd edition with all the content commented or styled out and will proceed by reviewing and updating content incrementally. 21:14:21 Topic: Info on upcoming review periods: 21:14:21 * HTML5 specs (LC period ends August 3) 21:14:21 http://www.w3.org/News/2011#entry-9105 21:14:21 * DOM 3 Events (proposed LC period end June 28) 21:14:21 http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html 21:14:25 agenda+ CSS and SVG charters 21:14:35 ed: do we need more time to review the specs? 21:15:11 heycam: are there specific things we need to pay attention to? 21:15:33 heycam: we do not particularly depend on any features on the DOM Events Level 3. Is that right? 21:15:56 shepazu: I am too close to the problem. I do not think it is going to affect SVG particularly one way or the other. 21:16:21 heycam: there might be interesting things to give input on. 21:16:51 shepazu: it has a very good keyboard model, which is good for SVG. But things like the event model have not changed. 21:17:18 shepazu: now can omit the last parameter in add/removeEventListener. I cannot think about anything SVG specific. 21:17:26 shepazu: may be SVG 2.0 will add new events. 21:17:56 ed: the reason I asked is that the email asked if we needed more time for review. If we do not need more time, then we can move on. 21:18:03 ed: the other spec. is the HTML5 spec. 21:18:13 ed: there is a bit more time for this spec. 21:18:31 heycam: there are SVG related things such as parsing, but we have moved on from these issues. 21:18:45 Topic: SVG Compositing - the "plus" mode 21:18:45 http://www.w3.org/mid/645F9695BBAE0846A01542C63A9B8CB23D50E68CB8@HQMAIL03.nvidia.com 21:18:56 ed: do we have an editor for this spec. 21:19:09 heycam: I thought Alex or Rik would take over. 21:19:23 Zakim, who is on the call? 21:19:23 On the phone I see jwatt, heycam, +1.408.536.aaaa, Doug_Schepers, ed, tbah 21:20:05 ed: we can talk about it on the mailing list. 21:20:22 Topic: SVG F2F 21:20:22 http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011 21:20:39 ed: shepazu, could you put up a questionaire for the F2F? 21:20:46 heycam: I think we can do it as chairs. 21:21:01 shepazu: I do not think I could get it in a timely manner. 21:21:36 ed, http://www.w3.org/2002/09/wbs/showwb 21:22:59 ACTION: ed to put up a questionaire for the Seatle F2F to clarify dates and attendance. 21:23:00 Created ACTION-3048 - Put up a questionaire for the Seatle F2F to clarify dates and attendance. [on Erik Dahlström - due 2011-06-02]. 21:23:25 vhardy: we have a request at Adobe to host. I am waiting for an answer. 21:24:56 Topic: SVG Open 2011 21:25:09 ed: can you be the chair of the SVG WG session. 21:25:12 heycam: yes. 21:27:15 Topic: SVG WG charter. 21:27:28 http://www.w3.org/2010/09/CSSWG/charter.html 21:27:51 http://www.w3.org/Graphics/SVG/WG/charter/2010/Overview.html 21:29:01 shepazu: there are some contradictions in the wording, e..,g CSS Animations v.s., Web Animations (we had agreement on the wording), CSS 2D/2D transformations. 21:29:27 shepazu: I would like to clarify that the SVG WG intends to work with the CSS WG on these things. Is that the expectation? 21:29:31 vhardy: yes. 21:29:42 heycam: as in having a single spec. 21:29:47 heycam: ? 21:30:43 heycam: we had a discussion about the transforms spec. during the FX call this week and decided to keep two separate specs. because we have lost an editor. 21:31:36 shepazu: for this discussion, I think I would like to coordinate with the CSS WG on the priorities, the spec. titles and the expectations on which specs. we work on together. 21:31:52 heycam: yes, I agree in particular about the Web Animations work. 21:31:57 -tbah 21:32:52 shepazu: I'll edit our charter first. Then we should talk with the CSS WG to keep things in sync. 21:33:06 heycam: yes, we need to have the same idea about how we are going to work together. 21:34:17 shepazu: please send comments to me. 21:34:27 shepazu: on the CSS and SVG WG charters. 21:34:58 shepazu: we need to coordinate on what the charters communicate. 21:36:03 shepazu: discussion on public-svg-wg@w3.org 21:42:38 - +1.408.536.aaaa 21:42:39 -heycam 21:42:41 -ed 21:42:45 -Doug_Schepers 21:42:48 -jwatt 21:42:49 GA_SVGWG(SVG1)4:00PM has ended 21:42:51 Attendees were heycam, +1.408.536.aaaa, Doug_Schepers, jwatt, rik, tbah, ed 21:43:34 RRSAgent, make minutes 21:43:34 I have made the request to generate http://www.w3.org/2011/05/26-svg-minutes.html vhardy 21:44:06 jwatt has left #svg 21:52:14 trackbot, end telcon 21:52:14 Zakim, list attendees 21:52:14 sorry, trackbot, I don't know what conference this is 21:52:15 RRSAgent, please draft minutes 21:52:15 I have made the request to generate http://www.w3.org/2011/05/26-svg-minutes.html trackbot 21:52:16 RRSAgent, bye 21:52:16 I see 4 open action items saved in http://www.w3.org/2011/05/26-svg-actions.rdf : 21:52:16 ACTION: heycam to collect initial email feedback on SVG 2.0 features the group should take on into a Wiki. [1] 21:52:16 recorded in http://www.w3.org/2011/05/26-svg-irc#T20-17-31 21:52:16 ACTION: shepazu to send emails to the stakeholder mailing lists (www-svg & svg Yahoo developers) lists to solicit feedback on the high priority features the group should take on, preferably with use cases and requirements. [2] 21:52:16 recorded in http://www.w3.org/2011/05/26-svg-irc#T20-19-01 21:52:16 ACTION: jwatt to do initial SVG 2.0 commit into Mercurial. [3] 21:52:16 recorded in http://www.w3.org/2011/05/26-svg-irc#T21-12-41 21:52:16 ACTION: ed to put up a questionaire for the Seatle F2F to clarify dates and attendance. [4] 21:52:16 recorded in http://www.w3.org/2011/05/26-svg-irc#T21-22-59