- From: Erik Dahlstrom <ed@opera.com>
- Date: Wed, 23 Mar 2011 21:21:37 +0100
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Minutes as html:
http://www.w3.org/2011/03/23-svg-minutes.html
and as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
23 Mar 2011
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0255.html
See also: [3]IRC log
[3] http://www.w3.org/2011/03/23-svg-irc
Attendees
Present
ed, anthony, [Microsoft], tav, heycam, Shepazu, adrianba
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Cameron
Contents
* [4]Topics
1. [5]SVG 1.1F2 progress
2. [6]SVG 2.0 editing strategy and authoring guide
3. [7]F2F in Japan
4. [8]TPAC
* [9]Summary of Action Items
_________________________________________________________
<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> [10]http://www.w3.org/2010/09/SVG1.1SE-LastCall/dump.html
[10] 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>
[11]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2/Specification_author
ing_guide
[11]
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> [12]http://www.w3.org/Graphics/SVG/WG/track/actions/3014
[12] 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> [13]http://www.w3.org/Graphics/SVG/WG/track/actions/2910
[13] 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
[14]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> [15]http://www.w3.org/blog/SVG/
[15] 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
Summary of Action Items
[NEW] ACTION: Doug to work on a proposal for markup conventions for
reviewing/porting spec text [recorded in
[16]http://www.w3.org/2011/03/23-svg-minutes.html#action01]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [17]scribe.perl version 1.135
([18]CVS log)
$Date: 2011/03/23 20:03:51 $
_________________________________________________________
[17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[18] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
Check for newer version at [19]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/new groups are working/new groups are not working/
Succeeded: s/no/... no/
Succeeded: s/coordinate/coordinate with/
Found Scribe: Cameron
Found ScribeNick: heycam
Default Present: ed, anthony, [Microsoft], tav, heycam, Shepazu, adrian
ba
Present: ed anthony [Microsoft] tav heycam Shepazu adrianba
Agenda: [20]http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMa
r/0255.html
[20]
http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0255.html
WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth
Found Date: 23 Mar 2011
Guessing minutes URL: [21]http://www.w3.org/2011/03/23-svg-minutes.html
People with action items: doug
[21] http://www.w3.org/2011/03/23-svg-minutes.html
End of [22]scribe.perl diagnostic output]
[22] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Wednesday, 23 March 2011 20:23:18 UTC