SVG Working Group Teleconference -- 23 Mar 2011

<trackbot> Date: 23 March 2011

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

SVG 1.1F2 progress

ED: I went over the DoC in the tracker
... to have a look at the ones where we hadn't marked that we got responses from commenters
... I fixed a couple of those in tracker
... so I think we have a handful, maybe 4 or 5 with no responses atm
... and 2 which are not addressed yet
... one of them is on whether the SVG root should be an event target, the other is the Changes appendix
... the other ones are just missing responses from the commenters, but all of those were very minor things like typos
... so I want to check what the status is on the remaining actions
... we need to close them off

CM: I got ACTION-3013, will that be for 1.1F2?

ED: we should get a proposal, and then see

CM: I didn't get time during the week to do that, but I should tomorrow

ED: my action there about spaces rendering is just an informative note, so it's not really holding the spec back
... the SVG root as event target is partially done
... some comments on the wording that's on the spec

DS: I'll work on that and finish it tonight
... I don't anticipate getting a reply from the commenter

ED: that's fine, as long as we address the comments from heycam and me
... Chris' changes appendix, is that something we should get someone to help with?
... the remaining part of course is the test suite
... not sure there's anything more we can do with the test suite at this point
... I changed one of the rect tests, to align it with what's in the spec at the moment

CM: I'll take a look at reviewing that

<ed> http://www.w3.org/2010/09/SVG1.1SE-LastCall/dump.html

ED: so we need to close off the DoC
... it's just the SVG root pointer events one

SVG 2.0 editing strategy and authoring guide

ED: I put this on the agenda to see what our strategy for editing the 2.0 spec will be
... will we make some skeleton with headings only?

AG: I thought we were going to look at using ReSpec

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
... rather than reimplement its functionality in ReSpec

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

DS: part of the benefit of using ReSpec is uniformity with other groups
... so one of the considerations should be rather than is it the easiest thing to do, instead is it the right thing to do
... having said that, ReSpec is probably more suited towards smaller specs than giant ones like SVG

AG: if we enhance our system enough and add enough ReSpec features to it, it could be the standard for large specs

DS: I think most new groups are not working on large specs
... and I think the existing groups are going to be the ones that already have their own build systems
... the more important aspect is uniformity in output
... appearance, and conventions
... on how to mark stuff up
... 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

AG: if our build system can have its output looking like ReSpec generated documents that'd be good

ED: I think ReSpec wouldn't offer us much more than consistent looking specs at the moment

DS: it's unfortunate if you need to swap in different spec conventions between different groups
... but if the current system is documented, that would help

RESOLUTION: We will use the existing SVG spec build system and continue to coordinate with other groups on format conventions

ACTION-3014?

<trackbot> ACTION-3014 -- Cameron McCormack to document current build system -- due 2011-03-28 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/3014

DS: going back to the 1.1 stuff, what will we do about the Changes appendix?

ED: Chris has an action to do that

<ed> ACTION-2910?

<trackbot> ACTION-2910 -- Chris Lilley to cleanup changes appendix for SVG Full 1.1 2nd Edition -- due 2010-11-25 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2910

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
... is that documented sufficiently to do that?
... no, but I will finish that wiki page today and email a link to you

ED: if we're using the existing build system, what will be our strategy to move things across?

DS: I had a proposal of something like this
... I really don't want to just import old text without it going through thorough review
... it might actually be less work for us to rewrite large sections of it than to import it and work around the text
... I suggest that anything we put in at all we mark up with a class "unreviewed"
... and the unreviewed has a visual appearance to make that obvious
... we should have a special class to mean this text has been imported just from 1.1, and not reviewed
... for sections that are rewritten from scratch, we can just have it marked reviewed
... 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"
... and my reply would be to try our best to capture the intent of these passages, and make things more explicit
... so for any text we should mark whether the text is reviewed
... for text ported over, we mark it as having come from 1.1
... maybe even in the build system, we could only output things that are approved, or maybe that's going too far
... the second part of this is that we have a review process
... one person submits something, and they ask someone to review it
... e.g. if Anthony wrote something about color interpolation he'd ask Chris for review
... going forward, just because something's approved wouldn't mean that it couldn't change in the future
... just that it was good enough for solid inclusion into the spec

CM: I like review
... wonder if requiring review of all spec text might slow things down

DS: there is a lot of text in 1.1 that isn't up to standard
... I think having commit then review process would help with this. if it's too heavyweight process, we can look at that later.

CM: I can see that

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
... one of the things that will change the most is rewording things such taht the normative requirements are very clear
... and that there's a minimum of discursive text that is of unclear status
... e.g. HTML5 goes too far, there's not enough context, reasoning for algorithms
... so we should make it clear what things are normative
... a given sentence shouldn't include normative and informative sentences
... if we have that one sentence isolated, we could mark that up with a class, give it an id
... 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
... that was the other final part of review
... we have text in the spec, that's great, but that's only part of the battle
... the other part is getting tests around that
... first phase for text in the spec is unreviewed
... phase 2 is reviewed
... phase 3 is reviewed and tests written
... I think that should be part of our spec writing process
... in telcons we can go by this process to hand out actions to write tests for text in phase 2, etc.
... 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
... I would like to see tests written for WD-level text
... implementors could be more confident in experimentally implementing WD-level text
... which I think could help speed up the REC track process

CM: I like it

DS: when I say "all the tests for that section have been written", I mean tests exclusively for that section
... not including combinatorial tests
... as a minimum criterion, having a test for every testable assertion in a section

CM: like calling out normative statements, but worry about styling making things unreadable

DS: in DOM 3 Events, I have two style sheets
... one that makes the testable assertions pop out
... we can play around with the styling

ED: the thing that worries me with the proposal is that it will start to get messy quickly
... I'm worrying when we start reviewing then changing the wording, do you keep the old text?
... sometimes I think it might be good to have a proper reviewing system for checkins, but that might be too involved
... in general I like the idea
... be good to have tests and review for things that are checked in
... do you want to go ahead and propose a format for how to move things across?

DS: did we decide to use hg already?

CM: I think so
... jwatt is working on the repository

<scribe> ACTION: Doug to work on a proposal for markup conventions for reviewing/porting spec text [recorded in http://www.w3.org/2011/03/23-svg-minutes.html#action01]

<trackbot> Created ACTION-3015 - Work on a proposal for markup conventions for reviewing/porting spec text [on Doug Schepers - due 2011-03-30].

DS: we might have an unreviewed section as a whole, but a reviewed sentence within that
... I'll propose some class names, and put up a wiki page for that
... I think the next concrete step is to start assigning actions
... someone to put the skeleton spec there
... maybe heycam and jwatt can make a template page

[discuss concerns from jwatt about the tabula rasa approach]

DS: how about we have a dummy 1.1 spec for our internal use, and mark things off explicit from it

AG: or we could just go it from a feature list

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
... 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
... we could edit the 1.1 spec and link to the new section
... if we go by features, I think we would be at risk of missing out on important spec text

[doug discusses how we might track which things have been moved over from 1.1 to 2.0]

[e.g. adding links from the internal 1.1 spec to the new sections in 2.0]

DS: this process is a good start
... I think it will help to give confidence to the community

TB: each part of the old spec would have links to where it would be in the new spec
... including links in the new spec to the old spec would be useful too

F2F in Japan

ED: have we heard back from Chris re coordination with CSS WG?

DS: they have discussed it but not made a decision
... he suggested we might consider having the F2F in Bilbao
... since that's where the AC meeting is going to be
... or maybe ERCIM, somewhere in Europe
... talking to MikeSmith about having a F2F in Japan
... he doesn't think recent events pose any real risk
... but he does think the rolling blackouts, problems with train cancellations, infrastructure problems, which might make a meeting logistically difficult
... that's where he'd express caution

ED: but it's still set to be at the same time?

DS: the CSS WG has not decided
... I think we can't make a decision until CSS have, since we want to colocate

ED: ok so we will hear move about what the CSS WG decides later

TPAC

ED: have you answered the qn for the WG?

CM: no
... we need to indicate whether we will meet for 1 or 2 days during the TPAC week
... and which days we would prefer if any
... I think we should have no preference on days
... and just indicate our preferences on which other groups we want to meet

AG: we only have 2 days of WG meeting just after SVG Open
... so meeting for 2 days during the TPAC week is a good idea

CM: we also need to decide which groups to coordinate with?
... CSS definitely

DS: HTML, and Web Apps
... Web Apps for the DOM stuff

CM: oh, for the DOM improvement stuff

DS: yeah

CM: HTML I'm not sure if there's much left to explicitly coordinate on

ED: we need to guess how many people will be attending too
... maybe 8-10?
... I don't know if Zynga rep has said anything yet

DS: I think they're still ramping up
... they will be attending the TPAC, don't know about other F2Fs

CM: also we need to consider overlap
... Web Apps for a couple of us
... CSS for Chris

ED: Fonts group also for Chris

DS: btw the systems team has revamped all the blogs, we're using wordpress

<shepazu> http://www.w3.org/blog/SVG/

DS: I'd like to have interviews with other browser vendors
... esp Opera and Mozilla
... so get in touch with me if you're willing to do interviews about your browsers
... (and other implementations)
... anyone who's a SVG WG member should have access here
... I think we should blog more

<ed> trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

23 Mar 2011

Attendees

Contents

SVG 1.1F2 progress

SVG 2.0 editing strategy and authoring guide

F2F in Japan

TPAC

Summary of Action Items

Scribe.perl diagnostic output