W3C home > Mailing lists > Public > www-svg@w3.org > November 2009

Minutes, 12 November 2009 SVG WG telcon

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Fri, 13 Nov 2009 08:46:29 +1100
Message-ID: <4AFC8235.3010807@cisra.canon.com.au>
To: www-svg@w3.org
http://www.w3.org/2009/11/12-svg-minutes.html

---

    [1]W3C

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

                                - DRAFT -

                    SVG Working Group Teleconference

12 Nov 2009

    See also: [2]IRC log

       [2] http://www.w3.org/2009/11/12-svg-irc

Attendees

    Present
           Shepazu, jwatt, [IPcaller], anthony

    Regrets
    Chair
           SV_MEETING_CHAIR

    Scribe
           jwatt, anthony

Contents

      * [3]Topics
          1. [4]F2F dates
          2. [5]Microsoft
      * [6]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 12 November 2009

    <scribe> scribe: jwatt

    <scribe> scribenick: jwatt

F2F dates

    AG: spoke erik - not available 18-22 Feb
    ... Cam not back until Q2 earliest
    ... jwatt not available in Feb
    ... or Jan
    ... so I'm wondering if we should do the F2F early March
    ... first week

    DS: I was thinking of going to Japan in Jan, and hoping to make it a
    single trip going back via AUS

    [discussion about times]

    AG: how about 10th - 14th Feb?

    [more discussion]

    JW: okay, that could hopefully work for me

    AG: I'll talk to Ed about those dates

Microsoft

    <shepazu>
    [7]http://lists.w3.org/Archives/Public/www-svg/2009Nov/0026.html

       [7] http://lists.w3.org/Archives/Public/www-svg/2009Nov/0026.html

    <shepazu> if MS were to implement SVG, how much of the DOM would be
    necessary for broad interoperability?

    <shepazu> as far as implementations, the most complete is probably
    Batik... then ASV (which is dwindling)... then the modern browsers
    (Opera, FF, Safari)...

    <shepazu> then there's the mobile UAs, but they use SVGT1.2's
    microdom...

    <shepazu> there's also compatibility with existing content to look
    at... it would be good to know how much of the corner-cases of the
    DOM are used in content

    <shepazu> note that Opera, FF, and WebKit implement different
    subsets of the DOM

    DS: there's a lot of good stuff in the SVG DOM, including
    unimplemented stuff, and there's a lot of stuff that was possibly
    not well thought out
    ... I think we're at a unique point where there's not a lot of
    content affected by DOM changes
    ... if we had a bunch of implementers that wanted to reconsider the
    DOM, we should maybe do that
    ... 1.2 Tiny is a complete departure from 1.1 Full anyway
    ... it would be a hard sell to some people, but if all the browser
    vendors wanted to do it, I'd we willing to look at it

    AG: I think it would be good to look at provided we keep backwards
    compatibility in mind

    DS: backwards compatibility could mean backwards compatibility with
    content OR implementations
    ... there's three different types of content to deal with
    ... 1) static content - not relevant here
    ... 2) content that uses basic DOM Level 1/2/3 stuff
    ... 3) content that uses particular things in the SVG DOM
    ... we're only at partial risk in 2, depending on how much we throw
    away or keep
    ... 3 is where our main risk is
    ... the importance I'd give is first content, then implementations,
    then specifications

    <anthony> AG: With backwards compatibility of implementations, we
    would only need to look at where implementations overlap

    JW: I'm mainly worried about implementation complexity and
    performance

    <anthony> scribe: anthony

    JW: The SVG DOM that are really negative for both
    ... especially the complex multiple levels of objects
    ... and object properties
    ... for certain attributes
    ... means you end up crossing the boundary between script and
    multiple implementations several times
    ... just to set multiple properties
    ... and these object heavy interfaces
    ... also add to implementation complexity
    ... if you are to avoid excessive memory use
    ... a lot of the time when I'm implementing DOM I sometimes wish we
    could start over and redesign it
    ... given the knowledge we have now
    ... but I've never felt that it was really possible

    DS: One thing I've been talking about with people recently
    ... is a DOM summit
    ... or workshop
    ... where we get together for 2 - 3 days with authors and developers
    ... people who are doing implementations and also people who
    experience with the SVG DOM making content with the SVG DOM
    ... and people who have experience with the Flex development and
    seeing if we can make a best of breed interface
    ... and API developers
    ... I've seen people who said they liked what the SVG WG came up
    with recently
    ... there are sort of general DOM optimisations
    ... then there is stuff that is useful for SVG and Graphics
    ... unified API for SVG and Canvas
    ... TC39 should be along for the summit as well
    ... I'd like to take a look at expanding the maths library so it
    deals with points and vectors
    ... and matrices

    JW: Math global?

    DS: Yes
    ... I think TC39 does the Math global

    JW: Yes it will be
    ... I'm kind of worried about getting so many people in the one room
    ... as your starting point

    AG: I agree

    JW: TC39 would not have any dependencies on SVG
    ... and I don't think they'd like that
    ... they would have to have dependencies on SVG

    DS: We could put the functions in the right places or where they
    belong

    JW: Java script library is probably the right place for that

    DS: Scrip libraries rarely do that one thing they are suppose to do.
    They always end up doing a whole bunch of other things
    ... and you end up having to download the whole library
    ... I think they are overused as a tactic for expanding the web

    JW: I agree at some point we want to take a script library and
    standardise the features
    ... once it's in the standard it becomes concrete

    DS: I understand your point JWatt, at what point is it appropriate
    to standardise

    AG: With the summit, you'd want to go in there with use case and
    requirements

    JW: I guess the main point here is should we be working on a new DOM
    ... I'm not sure how many people this will effect
    ... and how much content will be lost
    ... if people throw away their old implementations

    DS: Let's not pretend that the browsers have as complete
    implementation as Adobe did

    JW: I think Mozilla's implementation in certain places is more
    complete than Adobe's ever was

    DS: If we are worried about breaking compatibility with past content
    ... then that's already been done
    ... most of the content that was made back in the old days is not
    compatible with the implementations of today

    JW: I agree all the stuff that was written in the Adobe days is
    pretty much broken
    ... I'm worried that people made content we broke it
    ... then people have made new content
    ... then we break it again
    ... maybe that the content is small enough that for the sake of the
    benefits of the future out weigh the cost for breaking things again
    ... but still going to be a painful process
    ... I think the thing that might sway me to take the root of
    breaking backwards compatibility
    ... is the emergence of Web IDL which allows us to make much better
    interfaces
    ... Have a whole bunch of bulky stuff and it'd be nice to throw it
    away
    ... we'd have to publicize this
    ... and get feedback

    DS: I think MAMA is a good way to gauge what is out there

    <jwatt> s/feedback/feedback\/see how much we get flamed/

    DS: and having a good test suite would help

    JW: I think what you're talking about what is used in the wild
    ... is useful, but what I was talking about was making a list
    ... of things we might consider removing from the SVG DOM
    ... and saying "hey we're not thinking about throwing everything in
    the SVG DOM away, we are thinking of throwing away X, Y and Z"
    ... potential for less confusion

    DS: Obviously we'd have to get pretty concrete
    ... what's the next step?
    ... Maybe we should start on a specification
    ... nothing like a specification to get people talking
    ... we need to finish SVG Full 1.1 2nd Edition
    ... and start SVG 2.0
    ... and start with the DOM
    ... so next step is what?

    JW: Working on the specification is one thing
    ... should have a document somewhere saying we are thinking of doing
    this

    AG: How is that different from the current page?

    DS: Current page has future ideas

    AG: We should have a parent page

    DS: If I felt that everyone was along for the ride
    ... then I'd say let's go with SVG 2.0 and not worry about the past

    JW: Really I'd love to see the MAMA stuff and get the data
    ... and I don't want to commit to breaking suff

    DS: That would be what we need is feedback from the community
    ... we are fortunate that most of the content is static

Summary of Action Items

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [8]scribe.perl version 1.135
     ([9]CVS log)
     $Date: 2009/11/12 21:38:34 $
      _________________________________________________________

       [8] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
       [9] 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 [10]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

      [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/SVG DOM/Microsoft/
Succeeded: s/the/probably the/
Succeeded: s/one point/what point/
Succeeded: s/JW/DS/
Succeeded: s/Adobe/Adobe days/
Succeeded: s/with the/is the/
Succeeded: s/has allowed/which allows/
WARNING: Bad s/// command: s/feedback/feedback\/see how much we get fla
med/
Succeeded: s/starting over/throwing everything in the SVG DOM away/
Succeeded: s/some things away/away X, Y and Z/
Succeeded: s/stutt/suff/
Found Scribe: jwatt
Inferring ScribeNick: jwatt
Found ScribeNick: jwatt
Found Scribe: anthony
Inferring ScribeNick: anthony
Scribes: jwatt, anthony
ScribeNicks: jwatt, anthony
Default Present: Shepazu, jwatt, [IPcaller], anthony
Present: Shepazu jwatt [IPcaller] anthony

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 12 Nov 2009
Guessing minutes URL: [11]http://www.w3.org/2009/11/12-svg-minutes.html
People with action items:

      [11] http://www.w3.org/2009/11/12-svg-minutes.html

    End of [12]scribe.perl diagnostic output]

      [12] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 12 November 2009 21:47:06 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:43 GMT