- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Fri, 02 Apr 2010 07:50:07 +1100
- 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 UTC