W3C home > Mailing lists > Public > www-svg@w3.org > April 2010

Minutes SVG WG telcon Apr 1, 2010

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Fri, 02 Apr 2010 07:50:07 +1100
Message-ID: <4BB506FF.5040306@cisra.canon.com.au>
To: www-svg@w3.org

http://www.w3.org/2010/04/01-svg-minutes.html

---

    [1]W3C

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

                                - DRAFT -

                    SVG Working Group Teleconference

01 Apr 2010

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-svg-wg/2010JanMar/0110.html

    See also: [3]IRC log

       [3] http://www.w3.org/2010/04/01-svg-irc

Attendees

    Present
           [Microsoft], Shepazu, [IPcaller], ed, anthony

    Regrets
    Chair
           Erik

    Scribe
           Anthony

Contents

      * [4]Topics
          1. [5]Telcon Times
          2. [6]Publishing Schedule
          3. [7]XLink Href
          4. [8]Test Suite
      * [9]Summary of Action Items
      _________________________________________________________

    <trackbot> Date: 01 April 2010

    <scribe> Scribe: Anthony

    <scribe> ScribeNick: anthony

Telcon Times

    ED: I said that next telcon is canceled
    ... it'll be a public holiday for some

    <ed>
    [10]http://www.timeanddate.com/worldclock/fixedtime.html?day=1&month
    =4&year=2010&hour=20&min=0&sec=0&p1=0

      [10] 
http://www.timeanddate.com/worldclock/fixedtime.html?day=1&month=4&year=2010&hour=20&min=0&sec=0&p1=0

    ED: next one on will be April, Thur 8
    ... The time suggested by the script was
    ... Monday and Thursdays
    ... 8PM UTC

    DS: So it's an hour later
    ... the time is fine for me
    ... for JW it's 9pm and CL it's 10pm

    ED: My suggestion is to try this time for this telcon
    ... and see how it goes

    PD: Sounds like it's a good idea

    ED: Do we need to book this now?

    PD: I say do it now

    DS: I'll book this now

Publishing Schedule

    ED: We were kind of late with publishing some documents
    ... so not meeting the heartbeat requirement
    ... I remember we resolved to publish some specs
    ... but I couldn't find any resolutions when I searched through the
    mailing list

    PD: I remember there was a whole series of documents
    ... are we concerned with a certain one?

    ED: Mainly we were concerned with publishing modules
    ... Filters, composting

    PD: Don't really understand the publishing process

    DS: There's a heartbeat requirement
    ... where we are suppose to publish every 3 months
    ... we have Editors Draft
    ... which is fairly new in W3C
    ... then there is First Publich Working Draft
    ... where a company looks at it's IP and decides to go a head with
    it or not
    ... then there is Working Draft
    ... then it goes to Candidate Recommendation when we think it is
    almost done
    ... then there is Proposed Recommendation where people get a chance
    to comment
    ... then it moves to Recommendation status

    <patrick> [11]http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap

      [11] http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap

    PD: Looking a Wiki road map

    ED: That's a bit off

    DS: We've been really slowed down by SVG 1.1 2nd Edition
    ... I think it's were all over worked

    PD: I don't want to add anymore slowness

    ED: To push out 2nd edition would require some more work on test
    suite
    ... and some spec work
    ... which isn't too much more work

    PD: So I saw some drafts on Params, gradients
    ... and is it a matter of picking bits of those
    ... then building 2.0 or is it starting from scratch?

    DS: We have two different markets we are trying to satisfy
    ... Browsers and then mobile platforms
    ... The modules allow people to add SVG 2.0 functionality to their
    browsers
    ... once we know what modules we will have for 2.0
    ... we will collect them together with some other bits and we
    develop 2.0
    ... that way other user agents can inch their way to 2.0

    PD: I would like us a WG to take a far step back and look at SVG
    ... e.g. reduced DOM
    ... so if were to do something like reduced DOM would that be a new
    module or a chapter?

    DS: I could see the DOM as a module, but would probably be part of
    the core specification

    PD: Would the original DOM be part of the spec if we go with a new
    one

    DS: Personally, I think parts of it would be
    ... but we have an opportunity to redefine it here
    ... but it mainly getting the browser vendors to agree on new
    functionality

    PD: So then what's the responsibly. Would you list the old DOM bits
    optional and deprecated?

    DS: Yes

    ED: We will try to set up some more joint telcons for FX

    PD: That sounds great
    ... looking forward to the F2F

    ED: From my personal opinion there are definitely parts of SVG 1.1
    DOMM
    ... that are heavily used and useful
    ... then there are parts that are not well thought out
    ... if you ask anyone who's implemented SVG
    ... they will say they that there are parts that they'd like to
    change

    PD: What about higher level

    DS: We have most of the browser vendors participating
    ... we have people from Adobe if they want to participate
    ... I saw some Silverlight stuff that looked appropriate for SVG and
    some of it was not
    ... if we are going to set the course of future web graphics then we
    should take a look at some of these things here
    ... I think there is some useful stuff that we could be adding to
    SVG
    ... Parameters is one of those things that is not backwards
    compatible but most people have loved it
    ... and if you do that then most of the older SVG content in those
    older browsers will not work when using this
    ... I think we have a unique opportunity to change things now

    PD: So in summary we're not going to do a bottom up approach but
    more top down

    ED: So you're thinking more of a functionality and feature thing?

    PD: Yes

    DS: One examples is gradients for example
    ... SVG currently offers radial and linear gradients
    ... but I'd like as an author to have gradients along a path
    ... or something like gradient mesh or diffusion curves
    ... so we could come in from either end when designing SVG

    ED: This is definitely an interesting discussion to have. Should
    have this at the F2F
    ... having backwards compatibility is really important
    ... but certainly being able to extend it

    DS: I think we'd have to figure out in the details
    ... what to preserve and what to move forward with

XLink Href

    <shepazu> [12]http://dev.w3.org/SVG/profiles/2.0/publish/

      [12] http://dev.w3.org/SVG/profiles/2.0/publish/

    DS: Patrick you need to get your name on this as well

    <ed> [13]http://dev.w3.org/cvsweb/SVG/profiles/2.0/publish/

      [13] http://dev.w3.org/cvsweb/SVG/profiles/2.0/publish/

    DS: this didn't seem to print out a table of contents

    ED: Try the second link I pasted

    DS: I thought metadata wont change much

    <ed> [14]http://dev.w3.org/SVG/profiles/2.0/publish/metadata.html

      [14] http://dev.w3.org/SVG/profiles/2.0/publish/metadata.html

    DS: I took sections from 1.2 Tiny that you didn't think would change
    much
    ... and started adapting them

    <shepazu> [15]http://dev.w3.org/SVG/profiles/2.0/publish/intro.html

      [15] http://dev.w3.org/SVG/profiles/2.0/publish/intro.html

    DS: so far the most energy has gone into the intro page
    ... to set the tone what we are going to be doing
    ... there's just a few pages so far
    ... a few chapters
    ... I included linking
    ... because I want to talk about Link Href

    ED: That's one of the features that need to be changed because it's
    slightly different in Tiny
    ... quite like the page with the linking elements

    <shepazu>
    [16]http://dev.w3.org/SVG/profiles/2.0/publish/linking.html

      [16] http://dev.w3.org/SVG/profiles/2.0/publish/linking.html

    DS: What I want to do is allow 'src' on image

    <ed> ED: the linking restrictions were not as restricted in tiny
    1.2, so needs to be changed to represent 1.1 full

    DS: or have it on use as well
    ... anything that is sort of inbound
    ... and for replacement content
    ... and that leads us to a question

    <shepazu> <image xlink:href="foo.png" src="bar.jpg" ... />

    DS: what if you have something like this
    ... what do you do?

    PD: Xlink wins

    DS: What does the DOM look like?

    PD: It has both

    AG: I agree with PD on both of those

    <shepazu> <a xlink:href="foo.svg" href="bar.svg"> </a>

    ED: Probably makes the most sense

    <shepazu> myEl.href = "blah.svg"

    ED: Doesn't mean to say a new user agent wouldn't have a simpler way
    of accessing the link

    DS: What happens in the above case?

    PD: Both are in the DOM?

    DS: Yes
    ... my proposal is href changes both

    PD: Mirrored?

    DS: Yes mirrored

    PD: I don't like mirroring but at the same time this is an edge case

    DS: I think it's where things are backwards compatible

    ED: I'm not very fond of mirroring
    ... just trying to think of the case for backwards compatibility

    PD: It tends to have an unpredictable ripple effect from design and
    code
    ... you want to start moving on this right?

    DS: Yes, I want to have something quantified

    <shepazu> (and what would the namespace of the property be?)

    DS: we talked about this on the mailing lists and with other groups
    in the past

    PD: Is there anything similar already out there?

    ED: I think going over all the events and all the event attributes
    ... is something we need to do

    DS: One thing we could do is just say not add src
    ... just add href

    PD: I think href is a great start

    DS: There are some people that will get confused
    ... I actually don't know. I think people would like to get rid of
    the name space stuff

    PD: I think what we are saying though is that href is becoming part
    of the SVG name space

    DS: I mean right now what's reflected in the DOM
    ... the href would have the xlink namespace

    PD: I presumed href would be part of the NULL name space

    DS: What is the name space of that property?
    ... if we allowed just bare name href

    PD: What are we holding up on? Why is this so hard?

    DS: The question is when you're parsing the document and you
    encounter xlink:href it is very clear what you need to do
    ... if you're parsing a document and it has SVG image href without
    the xlink
    ... it puts the value in and it puts in a NULL names space
    ... what does the serialisation say?
    ... if they both exist in the DOM what happens?

    ED: I think they can have independent values in the DOM
    ... and serialise them as you would currently in browsers

    DS: You can't have two values with the same name
    ... one has prefix
    ... what if use dot notation to set it?
    ... which one does it change/set?

    ED: It changes which one we decide it to change

    DS: Honestly I don't care what the answer is
    ... it's messy either way

    <scribe> ... new people to SVG struggle with this one

    PD: we say xlink:href preceeds it and if .href is used what is
    changed xlink:href or href?

    DS: So opening up content in illustrator may break as well as a
    result
    ... is it worth getting rid of name spaces

    AG: What was the advantages of having name spaces in SVG?

    DS: You can use name spaces and prevent conflicts
    ... so say I wanted to put in some geolocation information in an SVG
    map
    ... I can distinguish between different sets of data using name
    spaces
    ... the mapping example is just one case
    ... it lets you structured data to SVG
    ... so in general I think some cases it's useful but with xlink:href
    it's not so much

    PD: How often are name spaces used on the web outside of SVG

    ED: XSLT style sheets outputting XHTML and HTML

    PD: Is that done a bit?

    ED: I've seen it out there

    DS: If it's supported it may be done some more

    ED: If we do drop xlink:href we need the tools to follow

    DS: Don't think we're closer to coming to a conclusion

    ED: Would be nice to collect all the thoughts and discussions on
    this
    ... we need a vote on this

    AG: Might be good to ask the IG what they think

    DS: What should I put in the SVG 2.0 spec next?

    ED: I don't think coordinate systems would change that much

    <ed> basic shapes too probably

    AG: We should consider adding information about processing elements
    ... and what steps should be done to process an element
    ... e.g. the spec talks about "at the time of reference" in various
    areas
    ... and it is unclear at what point in the processing are things
    reference
    ... this is an architectural that we should look at early on in the
    piece

    ED: So one little thing about publishing documents
    ... you said you'd look through the mailing list for decisions to
    publish
    ... I really think we need to get some documents out soon

    DS: Lets talk about that next Thursday

    <scribe> ACTION: Doug to Search through the minutes and look for
    where the group has made resolutions to publish [recorded in
    [17]http://www.w3.org/2010/04/01-svg-minutes.html#action01]

    <trackbot> Created ACTION-2751 - Search through the minutes and look
    for where the group has made resolutions to publish [on Doug
    Schepers - due 2010-04-08].

    <patrick>
    [18]http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_1.1F2

      [18] http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_1.1F2

Test Suite

    PD: I've updated the list

    DS: Can you please send an email out to let people know
    ... about the list
    ... and perhaps assign people to tests
    ... CL would be good with styling and stucture

    ED: There are a couple more tests
    ... that need review
    ... slightly more complex

Summary of Action Items

    [NEW] ACTION: Doug to Search through the minutes and look for where
    the group has made resolutions to publish [recorded in
    [19]http://www.w3.org/2010/04/01-svg-minutes.html#action01]

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [20]scribe.perl version 1.135
     ([21]CVS log)
     $Date: 2010/04/01 20:41:07 $
      _________________________________________________________

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

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/sence/sense/
Succeeded: s/image/link/
Succeeded: s/XHTML/XHTML and HTML/
Found Scribe: Anthony
Inferring ScribeNick: anthony
Found ScribeNick: anthony
Default Present: [Microsoft], Shepazu, [IPcaller], ed, anthony
Present: [Microsoft] Shepazu [IPcaller] ed anthony
Agenda: [23]http://lists.w3.org/Archives/Public/public-svg-wg/2010JanMa
r/0110.html
Found Date: 01 Apr 2010
Guessing minutes URL: [24]http://www.w3.org/2010/04/01-svg-minutes.html
People with action items: doug

      [23] http://lists.w3.org/Archives/Public/public-svg-wg/2010JanMar/0110.html
      [24] http://www.w3.org/2010/04/01-svg-minutes.html

    End of [25]scribe.perl diagnostic output]

      [25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 1 April 2010 20:50:44 GMT

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