06:31:51 <RRSAgent> RRSAgent has joined #svg
06:31:51 <RRSAgent> logging to http://www.w3.org/2009/05/20-svg-irc
06:31:53 <trackbot> RRSAgent, make logs public
06:31:53 <Zakim> Zakim has joined #svg
06:31:55 <trackbot> Zakim, this will be GA_SVGWG
06:31:55 <Zakim> ok, trackbot, I see GA_SVGWG()2:30AM already started
06:31:56 <trackbot> Meeting: SVG Working Group Teleconference
06:31:56 <trackbot> Date: 20 May 2009
06:32:00 <Zakim> +Doug_Schepers
06:32:30 <Zakim> +[IPcaller]
06:32:41 <Zakim> +??P2
06:32:46 <ed> Zakim, [IPcaller] is me
06:32:46 <Zakim> +ed; got it
06:32:50 <Zakim> +??P3
06:32:53 <anthony> Zakim, ??P2 is me
06:32:53 <Zakim> +anthony; got it
06:33:04 <jwatt> Zakim, ??P3 is me
06:33:04 <Zakim> +jwatt; got it
06:33:33 <ed> Zakim, pick a victim
06:33:33 <Zakim> Not knowing who is chairing or who scribed recently, I propose ed
06:33:35 <ed> Zakim, pick a victim
06:33:35 <Zakim> Not knowing who is chairing or who scribed recently, I propose Doug_Schepers
06:33:52 <anthony> Chair: Erik
06:33:55 <anthony> Scribe: anthony
06:34:09 <ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0144.html
06:34:40 <anthony> Topic: ISSUE-2271 - Add mechanism for variable stroke width (as in calligraphy)
06:34:44 <anthony> ISSUE-2271?
06:34:44 <trackbot> ISSUE-2271 -- Add mechanism for variable stroke width (as in calligraphy) -- RAISED
06:34:44 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2271
06:35:09 <anthony> ED: For us to consider way of doing variable stroke widths
06:35:22 <anthony> ... this is feature that's been requested a couple of times
06:35:40 <anthony> DS: I pointed to the threads there
06:35:45 <anthony> ... I pointed to my very early proposal
06:35:58 <anthony> ... not sure exactly how we should do it
06:36:18 <anthony> ... may or may not be able to do it with Vector Effects
06:36:32 <anthony> ... it's not hard to do this, it's just had to figure out the right way to specify these things
06:36:54 <anthony> ED: There is a mention here of one of the inkscape implementors
06:37:00 <anthony> ... have you spoken to him?
06:37:10 <anthony> DS: No, but he's very supportive of having this
06:37:23 <anthony> ... most Inkscape implementers like the idea
06:37:27 <anthony> ... they've implemented something
06:37:32 <anthony> ... but they just do it as a path
06:37:39 <anthony> s/implementors/implementers/
06:37:48 <anthony> DS: We should do a little more research into how we could do it
06:38:47 <anthony> ED: Two things to do
06:38:52 <anthony> ... talk to the Inkscape guys
06:39:01 <anthony> ... and gather use case and requirements on the wiki
06:39:23 <anthony> ACTION: Doug to Contact the Inkscape guys regarding variable stroke width (ideas, requirements)
06:39:24 <trackbot> Created ACTION-2563 - Contact the Inkscape guys regarding variable stroke width (ideas, requirements) [on Doug Schepers - due 2009-05-27].
06:41:33 <heycam> shepazu, when you've uploaded the errata document and test cases could you ping me, and then i'll mail out the notification to www-svg mentioning the changes, thanks.
06:41:48 <chrisl> chrisl has joined #svg
06:41:55 <anthony> Regrets: Cameron
06:42:11 <anthony> Topic: ISSUE-2015 - Should the svg element provide a duration element?
06:42:14 <anthony> ISSUE-2015
06:42:15 <anthony> ISSUE-2015?
06:42:16 <trackbot> ISSUE-2015 -- Should the svg element provide a duration element? -- RAISED
06:42:16 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2015
06:43:01 <anthony> ED: This is about specifying intrinsic animation have an animation and want to use it in another file
06:43:07 <anthony> ... and you want to specify the duration
06:43:15 <anthony> ... we don't have a way to specify the duration at the moment
06:43:50 <anthony> AG: Has Opera done anything like this?
06:44:04 <anthony> ED: I think it would be easy to add a 'dur' attribute to the SVG root element
06:44:15 <anthony> ... I'd be in favour of this
06:44:21 <anthony> ... the question is where would this go
06:44:24 <Zakim> +ChrisL
06:44:28 <anthony> ... in the structure chapter perhaps
06:44:34 <anthony> ... we don't have this as a module though
06:45:01 <anthony> ... we could add this to the main module
06:45:12 <anthony> ... or we could split the structure chapter into a module
06:45:19 <anthony> ... or a third option is specify this in a small file
06:45:23 <anthony> ... and stick it somewhere
06:45:59 <anthony> ... it would be useful to have something like this because it would animations much easier to reuse
06:46:30 <anthony> AG: I agree with putting it on the root element
06:46:52 <anthony> CL: This is so when an SVG is reference by another SVG element you say what the duration is?
06:46:54 <anthony> ED: Yes
06:47:08 <anthony> CL: Why can't you say that in the SVG itself
06:47:15 <anthony> ... on the animation element
06:47:39 <anthony> ED: You can specify the duration as a media on the animation element
06:47:57 <anthony> ... it's a good way of saying in the file how long your animation runs for
06:48:05 <ed> s/media/dur="media"/
06:49:33 <Zakim> -jwatt
06:49:56 <anthony> AG: What about if the intrinsic duration was shorter than an animation in the file?
06:50:07 <anthony> ED: I guess the intrinsic duration is good for repeats
06:50:17 <anthony> ... may cut off the animation
06:50:50 <anthony> AG: I don't really have an opinion on it
06:51:12 <anthony> ED: I could email Julien to see what he thinks and what behaviour he'd expect
06:51:19 <anthony> ... I can also try this out in Opera
06:52:11 <anthony> ACTION: Erik to Email Julien regarding intrinsic animation idea and what behaviour he'd expect
06:52:11 <trackbot> Created ACTION-2564 - Email Julien regarding intrinsic animation idea and what behaviour he'd expect [on Erik Dahlström - due 2009-05-27].
06:52:33 <Zakim> +??P3
06:52:37 <jwatt> Zakim, ??P3 is me
06:52:37 <Zakim> +jwatt; got it
06:52:43 <anthony> Topic: ISSUE-2022 - The activation behaviour of <a> elements should be defined
06:52:46 <anthony> ISSUE-2022?
06:52:46 <trackbot> ISSUE-2022 -- The activation behaviour of <a> elements should be defined -- RAISED
06:52:46 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2022
06:53:09 <anthony> ED: I had a look at the Tiny 1.2 spec
06:53:13 <anthony> ... it doesn't say that much
06:53:20 <anthony> ... doesn't have the text wording
06:53:27 <anthony> ... discussed in this issue
06:53:40 <anthony> ... we discussed it but I can't remember why it wasn't included in Tiny 1.2
06:53:47 <anthony> ... It looks like good wording to have
06:54:20 <chrisl> suggested text looks good to me.
06:54:27 <anthony> CL: Text looks good to me
06:54:33 <chrisl> clarifies, does not change conformance
06:54:36 <anthony> ED: Would this be ok to add as an errata
06:55:06 <anthony> ACTION: Anthony to Add the wording discussed in ISSUE-2022 to the Tiny 1.2 errata
06:55:06 <trackbot> Created ACTION-2565 - Add the wording discussed in ISSUE-2022 to the Tiny 1.2 errata [on Anthony Grasso - due 2009-05-27].
06:55:43 <anthony> AG: Category 3?
06:55:47 <anthony> CL: Yes I think so
06:56:00 <anthony> Topic: ISSUE-2024 - Elements for which "defer" can be used in preserveAspectRatio=""
06:56:04 <anthony> ISSUE-2024?
06:56:04 <trackbot> ISSUE-2024 -- Elements for which "defer" can be used in preserveAspectRatio="" -- RAISED
06:56:04 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2024
06:56:34 <anthony> ED: Can have defer inside of a preserveAspectRatio attribute
06:56:35 <chrisl> rrsagent, here
06:56:35 <RRSAgent> See http://www.w3.org/2009/05/20-svg-irc#T06-56-35
06:57:10 <anthony> JW: You can't reference an SVG from the image element
06:57:15 <anthony> ED: In Tiny 1.2 you can't
06:57:20 <anthony> ... in Full 1.1 you can
06:57:28 <anthony> s/element/element?/
06:57:53 <anthony> ... this is basically 1.2 Tiny errata?
06:58:13 <anthony> ... personally I think it's good to reference SVG images in the image element
06:58:20 <anthony> ... and they be static images
06:58:27 <anthony> ... similar to the img tag in HTML behaves
06:58:33 <anthony> JW: As similar as possible
06:58:48 <anthony> CL: SVG Full 1.1 was a bit ambiguous about that
06:58:56 <anthony> ... and didn't really say what happened
06:59:02 <anthony> ... we really need to clarify that as well
06:59:15 <anthony> ED: This basically splits into two actions
06:59:18 <anthony> ... one for fixing Tiny 1.2
06:59:43 <anthony> ... and one for clarifying 2.0 Full
07:00:00 <anthony> AG: Should it be an Issue on 2.0 and an action on Tiny 1.2?
07:00:06 <ed> http://www.w3.org/TR/SVGMobile12/coords.html#PreserveAspectRatioAttribute
07:00:35 <anthony> ED: I think that would be a small fix up
07:01:05 <anthony> ... and I don't think it would effect conformance
07:01:19 <anthony> CL: So you're saying that it already says you can't reference images?
07:01:23 <anthony> ... which spec?
07:01:30 <anthony> ED: In the linking chapter
07:01:31 <ed> http://www.w3.org/TR/SVGMobile12/linking.html#ReferenceRestrictions
07:01:42 <anthony> ED: In the table here
07:02:22 <anthony> ... the Image element is listed here
07:02:29 <anthony> ... won't get any visible results
07:02:53 <ed> a reference to an SVG document in <image> would be an invalid IRI reference, and would mean the element doesn't render
07:03:53 <anthony> ED: This would be category 2 then
07:05:24 <anthony> ACTION: Anthony to Add an errata item for Tiny 1.2 to remove the mention of "defer" in the image text
07:05:24 <trackbot> Created ACTION-2566 - Add an errata item for Tiny 1.2 to remove the mention of "defer" in the image text [on Anthony Grasso - due 2009-05-27].
07:05:54 <ed> to remove 'image' in the defer wording really, but ok :)
07:06:04 <anthony> Topic: ISSUE-2040 (Related to ISSUE-2045) - Consider adding placeholders or fallback for unresolved resources
07:06:09 <anthony> ISSUE-2040?
07:06:09 <trackbot> ISSUE-2040 -- Consider adding placeholders or fallback for unresolved resources -- RAISED
07:06:09 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2040
07:07:23 <anthony> ED: About having a way to fallback when something is unresolved, like an image
07:07:29 <anthony> CL: Like a broken image icon?
07:07:46 <anthony> ED: In Tiny 1.2 when the link is broken you get an invalid IRI reference
07:07:52 <anthony> ... and nothing is rendered
07:07:57 <anthony> ... so you don't know it's missing
07:08:06 <anthony> JW: Could this be done with a CSS property
07:08:26 <anthony> ... it seems like that it's something common with specs
07:08:55 <anthony> ED: What type of CSS property where you thinking of?
07:08:59 <anthony> JW: Something new
07:09:06 <anthony> ... dunno what it would be called
07:09:28 <anthony> CL: The initial value would be the current behaviour
07:09:36 <anthony> ... then do you point to a certain image?
07:09:50 <anthony> ... or a browser broken image picture?
07:09:58 <anthony> ... we should avoid binary values
07:10:20 <anthony> ... what about point to something else in the same file
07:10:28 <anthony> ... where you say draw this if the image doesn't load
07:10:37 <anthony> JW: I was thinking about the HTML img tag
07:10:49 <ed> s/img/object/
07:11:15 <anthony> CL: the object element allows you to have a child that displays the fallback content
07:11:24 <anthony> ... then in SMIL and SVG tend to do that with a switch
07:11:29 <anthony> ... not clear on what the condition would be
07:11:42 <anthony> ... another possibly would to evaluate whether the thing loaded
07:11:52 <anthony> DS: At one point we had wording in SVG Tiny 1.2
07:12:07 <anthony> ... that talked about what to do for fallback behaviour of raster images
07:12:10 <anthony> ... we took it out
07:12:13 <chrisl> in general we seem to use switch here, so a test attribute looks like  good solution
07:12:14 <anthony> ... and I can't remember why
07:12:25 <anthony> JW: That's an interesting suggestion Chris
07:12:46 <anthony> CL: So this is something that evaluates to True if the IRI reference is resolved
07:12:59 <anthony> ... then obviously you could draw anything you wanted to
07:13:01 <anthony> ... text, image
07:13:10 <anthony> JW: Like in the object tag
07:13:15 <anthony> ... you can have nested objects
07:13:18 <anthony> ...  until you find something that works
07:13:50 <anthony> ... I think it would be a good idea to have a cross spec solution
07:13:57 <anthony> CL: HTML has multiple ways of doing it
07:14:14 <anthony> ... I think currently if you put child content of an image it wouldn't be used as a fallback
07:14:34 <anthony> JW: I think that if you put this property in and it's consistent then it's something
07:14:42 <anthony> ... that could be deployed across documents
07:14:54 <anthony> ... I guess I need to come up with a more concrete suggestion
07:15:00 <anthony> ED: Two problems that we want to solve
07:15:12 <anthony> ... what to rendered if the content didn't specify and fallback and the link is broken
07:15:28 <anthony> ... and if you want some particular fallback behaviour how do you specify that
07:15:36 <anthony> ... the first one is a bit more easy to solve
07:15:44 <anthony> CL: We already have some of the options here
07:16:26 <anthony> ... At one point opera gives you a checkerboard if an image was broken
07:16:32 <anthony> ED: We used to
07:16:54 <anthony> CL: We got one of the options which is don't display anything
07:17:03 <anthony> ... the other two options there is no way to indicate what you want
07:17:12 <anthony> ED: There is external resources required
07:17:20 <anthony> ... which gives you an indication that something is broken
07:17:43 <anthony> CL: If we did have that for the switch case
07:18:03 <anthony> ... on the branch of the switch that has an image, you could put on there something says fail silently
07:18:17 <anthony> ... the reason I like the switch idea, is we already do that sort of thing
07:18:27 <anthony> ... we just need a test attribute to say if the link loaded or not
07:18:33 <anthony> JW: There scenarios?
07:18:45 <anthony> CL: A.svg points to an image
07:18:53 <anthony> ... only display it if it's completely correct
07:19:04 <anthony> ... option B is you fail silently
07:19:15 <anthony> ... option C is you fail with a visible indication
07:19:23 <anthony> ... don't have a way to specify B or C currently
07:19:42 <anthony> ... I suppose option D is the author provides a fallback and say explicitly what's to happen
07:19:51 <jwatt> so I guess I was thinking of a CSS property something like this: on-failure-display: nothing | children | error-pattern
07:20:22 <anthony> CL: Error-pattern, would that be a link?
07:20:43 <chrisl> ok so error-pattern means the default browser indication
07:21:04 <jwatt> so I guess rather than error-pattern, you could want two things
07:21:17 <jwatt> an error pattern specified by the spec and supplied by the UA
07:21:38 <jwatt> or a link to another piece of markup in the doc, sort of like a <use>
07:21:43 <jwatt> to provide your own pattern
07:21:59 <anthony> ED: Might be a way of solving it
07:22:16 <anthony> ... Suggest that the default value works based on what element it is on
07:22:39 <anthony> ... that's slightly different from Chris's idea of switching
07:22:58 <anthony> JW: It's not impossible to have two and decide which one is better
07:23:32 <anthony> ... going to other groups and figure out their requirements and get feedback
07:23:52 <anthony> CL: Would you be prepared to write up an email to CSS and HTML with the proposal?
07:24:51 <jwatt> s/decide which/let the user decide which/
07:25:09 <anthony> ... I think it would be just the CSS group that would have feedback
07:25:50 <chrisl> trackbot, status
07:26:46 <anthony> ACTION: Jonathan to Write up an email proposing the JWatt idea for fallback behaviour
07:26:46 <trackbot> Created ACTION-2567 - Write up an email proposing the JWatt idea for fallback behaviour [on Jonathan Watt - due 2009-05-27].
07:27:11 <anthony> ACTION: Chris to Write up an email proposing the Chris idea for fallback behaviour
07:27:11 <trackbot> Created ACTION-2568 - Write up an email proposing the Chris idea for fallback behaviour [on Chris Lilley - due 2009-05-27].
07:27:51 <anthony> ED: In the agenda I mention this issues is related to ISSUE-2045
07:28:00 <anthony> ... I'm not completely sure that this is exactly the same ore not
07:28:06 <anthony> ... but we have two that are very similar
07:28:11 <anthony> ... that issue has a note on it
07:28:17 <anthony> ... that comes from Bugzilla
07:28:21 <anthony> ISSUE-2045?
07:28:21 <trackbot> ISSUE-2045 -- Consider adding fallback behavior -- RAISED
07:28:21 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2045
07:29:09 <anthony> ED: I'm just wondering if the issues are different in someway or if we can close one of them
07:31:37 <anthony> AG: They look the same
07:31:52 <anthony> ... could close 2045 and add a note to 2040
07:31:55 <anthony> ED: Ok, I'll do that
07:33:44 <anthony> Topic: ISSUE-2054 - Consider removing the requirement for @width and @height for <foreignObject>
07:33:47 <anthony> ISSUE-2054?
07:33:47 <trackbot> ISSUE-2054 -- Consider removing the requirement for @width and @height for <foreignObject> -- RAISED
07:33:47 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2054
07:34:52 <anthony> CL: If you don't have width and height how do you figure out
07:34:56 <anthony> ... where to put it
07:35:02 <anthony> ... and how big it should be
07:35:17 <anthony> ED: The thing I was thinking of was use the width and height CSS properties
07:35:22 <anthony> ... allow them to define the size
07:35:31 <anthony> ... this mentions particularly MathML
07:36:12 <anthony> ... if you don't know what the size of the thing you embedded
07:36:18 <anthony> ... like the size of the MathML
07:36:40 <anthony> CL: Normally when we draw something you say what size it is
07:36:56 <anthony> ... what's the motivation for removing it?
07:37:02 <anthony> ... the audio case is different
07:37:18 <anthony> ... but for something that renders you'd want to say how big it is
07:37:36 <anthony> ... for audio the width and height would be 0
07:37:54 <anthony> ED: The audio wouldn't be heard
07:38:05 <anthony> CL: I seem to remember we discussed what was part of the render tree
07:38:10 <anthony> ... and if it was visual only
07:38:36 <anthony> ED: I do think it would be interesting to see if the width height CSS properties could be used
07:38:51 <anthony> ... such as the case where you have the SVG root element inside an XHTML document
07:39:25 <anthony> ... and you have width and height in CSS
07:39:32 <anthony> ... the size is negotiated
07:39:58 <anthony> ... so it probably be possible to do something with the elements that use width and height
07:40:08 <anthony> ... It would go inline with what Doug was suggesting
07:40:17 <anthony> ... which is make the SVG attributes into properties
07:40:44 <anthony> ... I would personally think that it would be interesting to specify width and height in CSS
07:40:54 <anthony> ... for the case where you have a bunch of images
07:41:10 <anthony> ... would there be any problems with trying to specifying something like this
07:41:20 <anthony> CL: Depends, I'd like to see how it would work
07:41:43 <anthony> ... need to consider the geometrical layout which is crucial for SVG
07:42:05 <anthony> ACTION: Erik to Draft a proposal to have width and height properties
07:42:05 <trackbot> Created ACTION-2569 - Draft a proposal to have width and height properties [on Erik Dahlström - due 2009-05-27].
07:44:47 <anthony> Topic: ISSUE-2042
07:44:52 <anthony> ISSUE-2042?
07:44:52 <trackbot> ISSUE-2042 -- Consider adding adding non-NS linking syntax -- RAISED
07:44:52 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2042
07:45:37 <anthony> ED: This us for consider adopting link:href in svg as href
07:45:49 <anthony> ... there has been a thread going on in SVG www
07:46:01 <anthony> ... I think Robin B seemed to be against it
07:46:16 <anthony> CL: That's odd in his XML paper he was arguing the other way
07:46:36 <anthony> ... maybe he's saying the change is too much now we already got it
07:46:43 <anthony> ED: That's the impression I got
07:46:47 <anthony> ... it would be a pretty big change
07:46:53 <anthony> ... to have some kind of alias
07:47:07 <anthony> ... it would be kind of messy at least in a transitional phase
07:47:17 <anthony> CL: We would need to say what happens if you put in both
07:47:25 <anthony> ... xlink:href and href
07:47:35 <anthony> ED: Some chases where it is problematic
07:47:41 <anthony> ... HTML uses different names
07:47:49 <anthony> ... for the hrefs on different tags
07:47:56 <anthony> CL: It's not only href
07:48:10 <anthony> ... there is somethings that give a src vs href functionality
07:48:14 <anthony> ... which mean different things
07:48:25 <anthony> ED: The question is then, is that more confusing
07:48:28 <anthony> ... ore less confusing
07:48:59 <anthony> CL: xlink:href always had an attribute that says whether it's replace or embed
07:49:14 <chrisl> s/:href//
07:49:37 <anthony> ED: xlink:show maybe?
07:49:40 <anthony> CL: That's the one
07:49:58 <anthony> ED: And we probably have about zero tests for that?
07:50:08 <anthony> CL: Right, but it's providing metadata
07:50:22 <anthony> ... it's telling something that knows about xlink but not about SVG what to do
07:50:41 <anthony> ... of course the number things that understand xlink and not SVG is zero
07:50:50 <anthony> ... this has come up before in discussion
07:51:01 <anthony> ... that if you were going to redesign xlink how would you do it
07:51:12 <anthony> ... they'd be remapped to ref and src
07:51:33 <anthony> ED: There are three values new, replace, embed
07:52:02 <anthony> CL: Instead of taking a single attribute that takes the URI, you'd have three ones that would take the URI and tell you what to do with it
07:52:11 <ed> (xlink spec says also 'other' and 'none')
07:52:22 <anthony> ... there are other things that xlink does as well
07:52:27 <anthony> ... which xlink:rel
07:52:33 <anthony> ... specifies relationships
07:52:54 <anthony> ED: If we were to replace or make a new name for the hrefs, which would be?
07:53:07 <anthony> CL: I'd tend to favour replacing href
07:53:28 <anthony> ED: And that would be overriding or the same?
07:53:42 <anthony> CL: It depends on our fallback strategy
07:54:02 <anthony> ... depends on if people want to write content that worked in both
07:54:17 <anthony> ... could have a similar situation with xml:id
07:54:50 <anthony> ... one possibility is you can specify href every where xlink:href can be put
07:54:55 <anthony> ... href takes priority
07:55:06 <anthony> ED: I'd make content with href and have a script
07:55:09 <anthony> ... that fixes it
07:55:12 <anthony> ... for older implementations
07:55:18 <anthony> ... there are some cases where that doesn't work
07:55:35 <anthony> ... I guess we should the whole thread on www-svg
07:55:38 <anthony> ... together
07:55:56 <anthony> ... then propose something, based on what everyone is saying
07:57:57 <anthony> ACTION: Chris to Go through the www-svg list regarding link:href and make a proposal based on the feedback
07:57:57 <trackbot> Created ACTION-2570 - Go through the www-svg list regarding link:href and make a proposal based on the feedback [on Chris Lilley - due 2009-05-27].
07:59:16 <Zakim> -ed
07:59:17 <Zakim> -ChrisL
07:59:17 <Zakim> -anthony
07:59:20 <Zakim> -jwatt
08:01:21 <anthony> Zakim, bye
08:01:21 <Zakim> leaving.  As of this point the attendees were Doug_Schepers, ed, anthony, jwatt, ChrisL
08:01:21 <Zakim> Zakim has left #svg
08:01:26 <anthony> RRSAgent, make minutes
08:01:26 <RRSAgent> I have made the request to generate http://www.w3.org/2009/05/20-svg-minutes.html anthony
11:16:27 <eseidel> eseidel has joined #svg