18:29:40 RRSAgent has joined #svg 18:29:40 logging to http://www.w3.org/2011/03/23-svg-irc 18:29:42 RRSAgent, make logs public 18:29:42 Zakim has joined #svg 18:29:44 Zakim, this will be GA_SVGWG 18:29:44 ok, trackbot; I see GA_SVGWG(SVG1)2:30PM scheduled to start in 1 minute 18:29:45 Meeting: SVG Working Group Teleconference 18:29:45 Date: 23 March 2011 18:30:45 anthony has joined #svg 18:30:55 GA_SVGWG(SVG1)2:30PM has now started 18:31:01 +[IPcaller] 18:31:08 Zakim, [IP is me 18:31:08 +ed; got it 18:31:43 +[IPcaller] 18:31:50 Zakim, [IP is me 18:31:50 +anthony; got it 18:32:38 tbah has joined #svg 18:33:00 +[Microsoft] 18:33:12 PDENGLER has joined #SVG 18:33:26 Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0255.html 18:34:35 +tav 18:34:50 +[IPcaller] 18:34:53 Zakim, [ is me 18:34:53 sorry, heycam, I do not recognize a party named '[' 18:35:00 Zakim, [IPcaller] is me 18:35:00 +heycam; got it 18:35:49 Zakim, who's here? 18:35:49 On the phone I see ed, anthony, [Microsoft], tav, heycam 18:35:50 On IRC I see PDENGLER, tbah, anthony, Zakim, RRSAgent, karl, shepazu, f1lt3r_bocoup, anthony_work, trackbot, heycam, dholbert, ed 18:35:59 +Shepazu 18:36:13 Scribe: Cameron 18:36:18 ScribeNick: heycam 18:36:39 Topic: SVG 1.1F2 progress 18:36:56 ED: I went over the DoC in the tracker 18:37:08 ... to have a look at the ones where we hadn't marked that we got responses from commenters 18:37:14 ... I fixed a couple of those in tracker 18:37:23 ... so I think we have a handful, maybe 4 or 5 with no responses atm 18:37:28 ... and 2 which are not addressed yet 18:37:44 ... one of them is on whether the SVG root should be an event target, the other is the Changes appendix 18:37:55 ... the other ones are just missing responses from the commenters, but all of those were very minor things like typos 18:38:06 ... so I want to check what the status is on the remaining actions 18:38:12 ... we need to close them off 18:38:50 CM: I got ACTION-3013, will that be for 1.1F2? 18:38:57 ED: we should get a proposal, and then see 18:39:19 CM: I didn't get time during the week to do that, but I should tomorrow 18:39:31 ED: my action there about spaces rendering is just an informative note, so it's not really holding the spec back 18:39:38 ... the SVG root as event target is partially done 18:39:46 ... some comments on the wording that's on the spec 18:40:00 DS: I'll work on that and finish it tonight 18:40:21 ... I don't anticipate getting a reply from the commenter 18:40:32 ED: that's fine, as long as we address the comments from heycam and me 18:40:36 agenda+ SVG WG blog 18:40:57 ED: Chris' changes appendix, is that something we should get someone to help with? 18:41:14 ... the remaining part of course is the test suite 18:41:23 ... not sure there's anything more we can do with the test suite at this point 18:41:33 ... I changed one of the rect tests, to align it with what's in the spec at the moment 18:41:54 CM: I'll take a look at reviewing that 18:42:13 http://www.w3.org/2010/09/SVG1.1SE-LastCall/dump.html 18:42:23 ED: so we need to close off the DoC 18:42:43 ... it's just the SVG root pointer events one 18:43:07 adrianba has joined #svg 18:43:13 Topic: SVG 2.0 editing strategy and authoring guide 18:43:26 ED: I put this on the agenda to see what our strategy for editing the 2.0 spec will be 18:43:35 ... will we make some skeleton with headings only? 18:44:55 +[Microsoft.a] 18:45:05 zakim, [Microsoft.a] is me 18:45:05 +adrianba; got it 18:47:30 AG: I thought we were going to look at using ReSpec 18:47:54 CM: jwatt and I have been discussing that recently and came to the conclusion that it would be less work to use the current build system and improve/simplify it 18:48:01 ... rather than reimplement its functionality in ReSpec 18:49:54 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2/Specification_authoring_guide 18:50:53 DS: part of the benefit of using ReSpec is uniformity with other groups 18:51:17 ... so one of the considerations should be rather than is it the easiest thing to do, instead is it the right thing to do 18:51:31 ... having said that, ReSpec is probably more suited towards smaller specs than giant ones like SVG 18:51:59 AG: if we enhance our system enough and add enough ReSpec features to it, it could be the standard for large specs 18:52:11 DS: I think most new groups are working on large specs 18:52:20 ... and I think the existing groups are going to be the ones that already have their own build systems 18:52:54 s/new groups are working/new groups are not working/ 18:55:59 ... the more important aspect is uniformity in output 18:56:06 ... appearance, and conventions 18:56:11 ... on how to mark stuff up 18:56:51 ... and how to approach the whole process of making decisions about what good prose is, the level of detail you'd go into, the use of conformance criteria, clear approaches to MUSTs and SHOULDs 19:00:50 AG: if our build system can have its output looking like ReSpec generated documents that'd be good 19:01:17 ED: I think ReSpec wouldn't offer us much more than consistent looking specs at the moment 19:04:11 DS: it's unfortunate if you need to swap in different spec conventions between different groups 19:04:19 ... but if the current system is documented, that would help 19:05:06 RESOLUTION: We will use the existing SVG spec build system and continue to coordinate with other groups on format conventions 19:06:05 ACTION-3014? 19:06:05 ACTION-3014 -- Cameron McCormack to document current build system -- due 2011-03-28 -- OPEN 19:06:05 http://www.w3.org/Graphics/SVG/WG/track/actions/3014 19:06:26 DS: going back to the 1.1 stuff, what will we do about the Changes appendix? 19:06:30 ED: Chris has an action to do that 19:06:51 ACTION-2910? 19:06:51 ACTION-2910 -- Chris Lilley to cleanup changes appendix for SVG Full 1.1 2nd Edition -- due 2010-11-25 -- OPEN 19:06:51 http://www.w3.org/Graphics/SVG/WG/track/actions/2910 19:07:54 DS: one thing I'll probably need to do to finish my action is to make sure I have the spec conventions right, and figure out how to use the build system 19:07:58 ... is that documented sufficiently to do that? 19:10:32 no, but I will finish that wiki page today and email a link to you 19:10:36 s/no/... no/ 19:10:47 ED: if we're using the existing build system, what will be our strategy to move things across? 19:10:52 DS: I had a proposal of something like this 19:11:19 ... I really don't want to just import old text without it going through thorough review 19:11:37 ... it might actually be less work for us to rewrite large sections of it than to import it and work around the text 19:11:52 ... I suggest that anything we put in at all we mark up with a class "unreviewed" 19:12:01 ... and the unreviewed has a visual appearance to make that obvious 19:12:59 ... we should have a special class to mean this text has been imported just from 1.1, and not reviewed 19:13:15 ... for sections that are rewritten from scratch, we can just have it marked reviewed 19:13:40 ... I think Chris would say to this "there are partso f the spec that are really nuanced, we worded them a certain way for a reason, and there's a risk of losing some of the intent if things are dramatically rewritten" 19:13:57 ... and my reply would be to try our best to capture the intent of these passages, and make things more explicit 19:14:03 ... so for any text we should mark whether the text is reviewed 19:14:10 ... for text ported over, we mark it as having come from 1.1 19:14:29 ... maybe even in the build system, we could only output things that are approved, or maybe that's going too far 19:14:34 ... the second part of this is that we have a review process 19:14:46 ... one person submits something, and they ask someone to review it 19:15:04 ... e.g. if Anthony wrote something about color interpolation he'd ask Chris for review 19:15:29 ... going forward, just because something's approved wouldn't mean that it couldn't change in the future 19:15:37 ... just that it was good enough for solid inclusion into the spec 19:18:02 CM: I like review 19:18:15 ... wonder if requiring review of all spec text might slow things down 19:18:27 DS: there is a lot of text in 1.1 that isn't up to standard 19:18:53 ... I think having commit then review process would help with this. if it's too heavyweight process, we can look at that later. 19:19:13 CM: I can see that 19:19:35 DS: one of the ways 1.1 is suboptimal is that we have a higher standard for normative text now, than when SVG 1.1 first came on the scene 19:19:53 ... one of the things that will change the most is rewording things such taht the normative requirements are very clear 19:20:06 ... and that there's a minimum of discursive text that is of unclear status 19:20:29 ... e.g. HTML5 goes too far, there's not enough context, reasoning for algorithms 19:20:42 ... so we should make it clear what things are normative 19:21:10 ... a given sentence shouldn't include normative and informative sentences 19:21:39 ... if we have that one sentence isolated, we could mark that up with a class, give it an id 19:21:54 ... when we're building our test suite, we can make it very clear how we link back and forth between the tests and the spec 19:22:00 ... that was the other final part of review 19:22:10 ... we have text in the spec, that's great, but that's only part of the battle 19:22:18 ... the other part is getting tests around that 19:22:27 ... first phase for text in the spec is unreviewed 19:22:31 ... phase 2 is reviewed 19:22:38 ... phase 3 is reviewed and tests written 19:22:47 ... I think that should be part of our spec writing process 19:23:12 ... in telcons we can go by this process to hand out actions to write tests for text in phase 2, etc. 19:23:37 -tav 19:23:50 ... this sounds heavy and process oriented, but I really do think we could stand to be a bit more systematic about how we do this 19:24:05 +tav 19:25:01 ... I would like to see tests written for WD-level text 19:26:40 ... implementors could be more confident in experimentally implementing WD-level text 19:26:48 ... which I think could help speed up the REC track process 19:26:59 CM: I like it 19:28:53 DS: when I say "all the tests for that section have been written", I mean tests exclusively for that section 19:28:57 ... not including combinatorial tests 19:29:18 ... as a minimum criterion, having a test for every testable assertion in a section 19:31:01 CM: like calling out normative statements, but worry about styling making things unreadable 19:31:10 DS: in DOM 3 Events, I have two style sheets 19:31:17 ... one that makes the testable assertions pop out 19:31:22 ... we can play around with the styling 19:31:45 ED: the thing that worries me with the proposal is that it will start to get messy quickly 19:32:03 ... I'm worrying when we start reviewing then changing the wording, do you keep the old text? 19:32:14 ... sometimes I think it might be good to have a proper reviewing system for checkins, but that might be too involved 19:32:17 ... in general I like the idea 19:32:23 ... be good to have tests and review for things that are checked in 19:32:35 ... do you want to go ahead and propose a format for how to move things across? 19:32:59 DS: did we decide to use hg already? 19:33:02 CM: I think so 19:33:08 ... jwatt is working on the repository 19:33:54 ACTION: Doug to work on a proposal for markup conventions for reviewing/porting spec text 19:33:55 Created ACTION-3015 - Work on a proposal for markup conventions for reviewing/porting spec text [on Doug Schepers - due 2011-03-30]. 19:34:06 DS: we might have an unreviewed section as a whole, but a reviewed sentence within that 19:34:36 ... I'll propose some class names, and put up a wiki page for that 19:34:48 ... I think the next concrete step is to start assigning actions 19:34:57 ... someone to put the skeleton spec there 19:35:22 ... maybe heycam and jwatt can make a template page 19:35:26 -adrianba 19:35:29 -[Microsoft] 19:38:15 [discuss concerns from jwatt about the tabula rasa approach] 19:38:38 DS: how about we have a dummy 1.1 spec for our internal use, and mark things off explicit from it 19:38:43 AG: or we could just go it from a feature list 19:38:58 DS: i think if we do it from a copy of the 1.1 spec itself, we can easily see which paragraphs have and haven't been ported 19:39:22 ... if what we have at the end of the process is an annotated SVG 1.1 that we mark as "this has been ported over", and we link to the new section 19:39:34 ... we could edit the 1.1 spec and link to the new section 19:40:08 ... if we go by features, I think we would be at risk of missing out on important spec text 19:43:30 [doug discusses how we might track which things have been moved over from 1.1 to 2.0] 19:43:45 [e.g. adding links from the internal 1.1 spec to the new sections in 2.0] 19:45:59 DS: this process is a good start 19:46:14 ... I think it will help to give confidence to the community 19:46:30 TB: each part of the old spec would have links to where it would be in the new spec 19:46:45 ... including links in the new spec to the old spec would be useful too 19:48:30 Topic: F2F in Japan 19:48:48 ED: have we heard back from Chris re coordination with CSS WG? 19:48:56 DS: they have discussed it but not made a decision 19:49:04 ... he suggested we might consider having the F2F in Bilbao 19:49:14 ... since that's where the AC meeting is going to be 19:49:22 ... or maybe ERCIM, somewhere in Europe 19:50:02 ... talking to MikeSmith about having a F2F in Japan 19:50:18 ... he doesn't think recent events pose any real risk 19:50:44 ... but he does think the rolling blackouts, problems with train cancellations, infrastructure problems, which might make a meeting logistically difficult 19:51:02 ... that's where he'd express caution 19:51:12 ED: but it's still set to be at the same time? 19:51:16 DS: the CSS WG has not decided 19:51:31 ... I think we can't make a decision until CSS have, since we want to colocate 19:52:56 ED: ok so we will hear move about what the CSS WG decides later 19:53:02 Topic: TPAC 19:53:11 ED: have you answered the qn for the WG? 19:53:12 CM: no 19:55:16 ...we need to indicate whether we will meet for 1 or 2 days during the TPAC week 19:55:24 ... and which days we would prefer if any 19:55:30 ... I think we should have no preference on days 19:55:36 ... and just indicate our preferences on which other groups we want to meet 19:55:48 AG: we only have 2 days of WG meeting just after SVG Open 19:55:56 ... so meeting for 2 days during the TPAC week is a good idea 19:56:18 CM: we also need to decide which groups to coordinate? 19:56:38 s/coordinate/coordinate with/ 19:56:58 CM: CSS definitely 19:57:03 DS: HTML, and Web Apps 19:57:07 ... Web Apps for the DOM stuff 19:57:42 CM: oh, for the DOM improvement stuff 19:57:43 DS: yeah 19:57:49 CM: HTML I'm not sure if there's much left to explicitly coordinate on 19:58:08 ED: we need to guess how many people will be attending too 19:58:14 ... maybe 8-10? 19:58:30 ... I don't know if Zynga rep has said anything yet 19:58:35 DS: I think they're still ramping up 19:58:42 ... they will be attending the TPAC, don't know about other F2Fs 20:00:00 CM: also we need to consider overlap 20:00:04 ... Web Apps for a couple of us 20:00:06 ... CSS for Chris 20:00:11 ED: Fonts group also for Chris 20:00:55 DS: btw the systems team has revamped all the blogs, we're using wordpress 20:01:14 http://www.w3.org/blog/SVG/ 20:01:34 ... I'd like to have interviews with other browser vendors 20:01:39 ... esp Opera and Mozilla 20:01:48 ... so get in touch with me if you're willing to do interviews about your browsers 20:01:59 ... (and other implementations) 20:02:07 ... anyone who's a SVG WG member should have access here 20:02:13 ... I think we should blog more 20:02:45 -heycam 20:03:24 -Shepazu 20:03:25 -ed 20:03:27 -anthony 20:03:35 -tav 20:03:36 GA_SVGWG(SVG1)2:30PM has ended 20:03:38 Attendees were ed, anthony, [Microsoft], tav, heycam, Shepazu, adrianba 20:03:44 trackbot, end telcon 20:03:44 Zakim, list attendees 20:03:44 sorry, trackbot, I don't know what conference this is 20:03:45 RRSAgent, please draft minutes 20:03:45 I have made the request to generate http://www.w3.org/2011/03/23-svg-minutes.html trackbot 20:03:46 RRSAgent, bye 20:03:46 I see 1 open action item saved in http://www.w3.org/2011/03/23-svg-actions.rdf : 20:03:46 ACTION: Doug to work on a proposal for markup conventions for reviewing/porting spec text [1] 20:03:46 recorded in http://www.w3.org/2011/03/23-svg-irc#T19-33-54