SVG Working Group Teleconference -- 01 Apr 2010

<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> 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> 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> http://dev.w3.org/SVG/profiles/2.0/publish/

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

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

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

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

- DRAFT -

SVG Working Group Teleconference

01 Apr 2010

Attendees

Contents

Telcon Times

Publishing Schedule

XLink Href

Test Suite

Summary of Action Items

Scribe.perl diagnostic output