- 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:55 UTC