W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2011

Minutes, 23 March 2011 SVG WG telcon

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>
Message-ID: <op.vstb6bzygeuyw5@197-180.anonymous.at.anonine.com>
Minutes as html:


and as text below:


       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

23 Mar 2011



    See also: [3]IRC log

       [3] http://www.w3.org/2011/03/23-svg-irc


           ed, anthony, [Microsoft], tav, heycam, Shepazu, adrianba




      * [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

    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
    ... 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



    DS: part of the benefit of using ReSpec is uniformity with other
    ... 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


    <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

    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

    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
    ... 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

    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
    ... 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
    ... 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
    ... 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

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

    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

    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

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


    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

    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

    <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

    [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

      [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
Present: ed anthony [Microsoft] tav heycam Shepazu adrianba
Agenda: [20]http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMa


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:22:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:13 UTC