IRC log of svg on 2011-03-23

Timestamps are in UTC.

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