IRC log of svg on 2010-05-26

Timestamps are in UTC.

07:13:10 [RRSAgent]
RRSAgent has joined #svg
07:13:10 [RRSAgent]
logging to http://www.w3.org/2010/05/26-svg-irc
07:13:12 [trackbot]
RRSAgent, make logs public
07:13:14 [trackbot]
Zakim, this will be GA_SVGWG
07:13:14 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
07:13:15 [trackbot]
Meeting: SVG Working Group Teleconference
07:13:15 [trackbot]
Date: 26 May 2010
07:13:50 [ed]
Zakim, remind me in 8 hours to take a break
07:13:50 [Zakim]
ok, ed
07:17:11 [AlexD]
AlexD has joined #svg
07:35:56 [leonardr]
leonardr has joined #svg
07:36:00 [leonardr]
http://www.lyrics007.com/Berlin%20Lyrics/The%20Metro%20Lyrics.html
07:36:11 [shepazu]
shepazu has joined #svg
07:46:09 [leonardr]
for future reference, computers need to be turned on before they can be used...
07:49:57 [fat_tony]
fat_tony has joined #svg
07:56:20 [jwatt]
jwatt has joined #svg
07:56:55 [ed]
Topic: SVG 2.0
07:57:10 [jwatt]
scribenick: jwatt
07:58:59 [jwatt]
PD: the main use cases for SVG we came up with were scalability, high fidelity, printing
08:03:50 [AlexD]
Printing - could you perhaps elaborate on use cases?
08:06:34 [jwatt]
PD: a printing example: we have a CAD program that outputs SVG, and it's very accurate
08:09:18 [jwatt]
...if for example out building layout software was able to do that, we could create a quick webapp to print building layouts to help with navigation, or office moves
08:11:44 [jwatt]
DS: a CAD company I've talked to has told me they're not interested in SVG, partly because it gets in the way
08:11:51 [jwatt]
PD: it would be good to find out why
08:12:48 [AlexD]
Patrick - years ago I had a slide presentation comparing the feature sets of SVG Tiny vs. XPS. There are many parallels in the graphics model. How would you see XPS vs. SVG as competing/complementary, or XPS failed in the market so it's irrelevant and open standards provide a web compatible print option?
08:13:03 [jwatt]
LR: these types of companies often have their own solutions that work for them already
08:14:12 [jwatt]
ED: one thing that worries me is that very detail plans, for example, result in huge files
08:14:50 [jwatt]
...which if you're on a phone or on a slow network is a problem
08:15:41 [jwatt]
LR: memory use for large files isn't so much of an issue if you know you don't need a DOM
08:16:40 [jwatt]
PD: our compliance department has looked into which international organizations require SVG support
08:16:59 [jwatt]
...there are 17 at required, and dozens on the way
08:17:15 [jwatt]
...from recommended to required
08:19:08 [jwatt]
PD: AlexD: I'd never thought of them as competing, we use XPS as a print format
08:19:50 [jwatt]
LR: yes, once everything settled, nobody wanted XPS as a document format, only as a principle format
08:22:12 [jwatt]
PD: SVG allows tooling
08:23:17 [ed]
...more easily due to it being an xml format
08:23:24 [AlexD]
So Leonard, how do you see the MARS SVG print thing fitting into all of this?
08:24:26 [AlexD]
We had SVG-print going, it was stillborn the Adobe developed MARS, is this of use and how is it relevant to SVG on the web...
08:24:40 [AlexD]
s/the Adobe/then Adobe/
08:27:34 [leonardr]
i'll answer that in a sec...in the midst of a separate discussion...
08:29:22 [leonardr]
At this time, Adobe has no plans for Mars - we found that there was not enough user interest :(. However, we would be interested in discussions with this committee (or others) about taking it over...
08:30:15 [jwatt]
(general agreement that the WG focus should be on both standalone and integrated SVG, rather than just standalone as it has been historically)
08:33:26 [jwatt]
LR: Mars is abandoned
08:35:28 [jwatt]
LR: we'd be happy to turn it over to anyone who wanted it
08:36:15 [jwatt]
DS: it would be nice if Adobe could make that a member's submission
08:37:48 [jwatt]
LR: one of the usecases we always saw and which we think is now coming into its own is as a graphics interchange format
08:37:54 [jwatt]
...clipart is a great example
08:38:59 [jwatt]
DS: scrapbooking uses crickets (a cutting printer) which use SVG as their format
08:39:22 [pdengler]
pdengler has joined #svg
08:39:27 [shepazu]
http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
08:39:51 [jwatt]
LR: we released FXG
08:39:59 [jwatt]
...which is really close to SVG
08:40:08 [jwatt]
...there are two reasons we didn't use SVG
08:40:35 [jwatt]
...we wanted to throw out all the stuff that's not useful for an exchange format: scripting, effects, etc
08:41:39 [AlexD]
At the moment ePub is big for pagination. It's basically HTML+SVG and some viewers use XSL-FO to drive the pagination side of things (but not the FO formatting model). So it's a bit more webby - being HTML+SVG. This is where we're heading. Mars was a single SVG file per page, a lot like the SVG Print proposals where it creates final form markup - similar to XPS in fact. So, we need to consider the use cases already put forward for SVG print, the ePub ecosystem and
08:41:41 [jwatt]
...the other reason was that we were using it for flash graphics, and it made implementation easier to make the object names in the XML to match the Flash DOM
08:42:10 [jwatt]
...so rather than have a name converter, it was easier to have different names to SVG
08:43:15 [ed]
AlexD: yes, we did discuss epub export here, didn't get scribed apparently
08:43:17 [jwatt]
DS: so we've been doing work on having profiles so you can disable script, for example
08:44:19 [jwatt]
LR: in ePub you may not want scripting, but could want declarative animation
08:47:22 [jwatt]
LR: I think graphics interchange format should definitely be a goal for SVG
08:52:59 [jwatt]
JW: my main use cases for getting into SVG were to provide more powerful educational material, and data visualisation
08:53:38 [jwatt]
...for example script changing the parameters on a SMIL an engine piston engine diagram
08:54:19 [jwatt]
...and script and animation of vector diagrams makes data visualization so much more powerful
08:55:15 [ed]
ED: for me, being able to take an SVG and remix/edit the graphic is what the web is about, ties into the whole interchange format discussion
08:55:50 [jwatt]
...Mozilla's focus is naturally much more on Web usecases than on data interchange
08:56:19 [jwatt]
LR: well for things like your Air equivalent exchange becomes relevant to you too
08:56:54 [jwatt]
...webapps too
08:57:19 [AlexD]
With web focus/data interchange etc. One of the nice things is that it's XML so you can use a text editor or a graphics tool like Illustrator, InkScape etc. Some of them use proprietary things to mark layers, etc. Should we consider meta-markup to indicate structure to help the graphics interchange stuff perhaps?
09:01:38 [pdengler]
We think that this is what the XML format is for. Doug notes tha the W3C should consider that outside the scope of SVG
09:07:17 [jwatt]
PD: one of the usecases I was thinking of was as image maps
09:09:35 [jwatt]
DS: I'm starting to see gradients, filter, transforms and others as more styling things, rather than as SVG features
09:10:23 [AlexD]
Patrick, one thing that I'd like you to consider. I've done a lot of work on IE unrelated to our plugin in the general area of printing. One thing that is glarngly missing when printing to XPS is a connection between semantic content such as hyperlinks and what gets emitted to the print stream. XPS has the capability to represent hyperlinks in its format. The only thing that generates those is Word with the XPS export function (not the print path). So if IE9 intro
09:11:16 [AlexD]
s/glarngly/glaringly/
09:13:05 [jwatt]
PD: I agree, although SVG introduced and showed leadership with these types of features, I think we need to have a move to develop them more holistically across other formats
09:14:13 [pdengler]
Yes, and as Doug stated we want to think about gradients, filters, transforms and anything that is a 'paint server' as styling, i.e. not a core deliverable of SVG
09:15:19 [jwatt]
ED: as I see it, yes, these belong in the CSS group to some extent, but I'm not sure that that group is interested in defining filter changes
09:15:24 [jwatt]
...I think that belongs in our group
09:15:43 [jwatt]
PD: yes, what we have is a lot more powerful than what CSS is looking at
09:15:59 [jwatt]
...Doug's SVG Wow demo was amazing
09:16:15 [ed]
s/filter changes/arbitrary filter chains/
09:16:24 [jwatt]
...but could those 17 chained filters be written with a tool
09:16:28 [jwatt]
ED: yes
09:16:32 [jwatt]
DS: yes
09:17:19 [jwatt]
DS: canned filters should definitely be defined is CSS though
09:18:04 [jwatt]
...Firefox lets you reference filter chains defined in SVG using CSS to apply to any content
09:18:34 [jwatt]
PD: so CSS lets you reference SVG filters
09:20:13 [jwatt]
LR: but tools take care of complexity
09:20:15 [jwatt]
PD: the vast majority of Web developers are what we call "notepad developers"
09:20:44 [jwatt]
...we've been waiting for them to switch to more powerful tooling, but it's just not going to happen
09:21:08 [jwatt]
DS: yes, tools won't really save us
09:21:27 [jwatt]
LR: I just don't want us to go completely down the road of view-source'ing
09:22:07 [jwatt]
...if the goal is to better integrate SVG with these other standards (and I think that's a good goal), do we have the latitude to throw out stuff?
09:22:12 [jwatt]
...I'm talking high level
09:22:30 [jwatt]
...if it were me, I would throw out all the stuff we don't need any more
09:22:42 [jwatt]
...anything that can go into a more general standard
09:22:57 [jwatt]
...backwards compatibility would not be a priority
09:23:21 [jwatt]
...or rather, a 2.0 consumer would not have to be able to consume 1.x
09:23:40 [jwatt]
PD: there are big features I'd deprecate moving forward
09:23:44 [jwatt]
...SVG fonts for example
09:24:01 [jwatt]
...we didn't implement them simply because there are better alternatives now
09:24:27 [jwatt]
...the story around CSS transitions, animations, scripting and SMIL needs to be sorted out
09:24:35 [jwatt]
...I want one method to do animations
09:24:55 [jwatt]
...I want queue's and transitions
09:25:31 [jwatt]
...the transitions is a better spec, but the css animations not so clear
09:25:49 [jwatt]
...we didn't implement filters yet, because of the compeating
09:26:22 [jwatt]
...the SVG filters are powerful, but the web developer is not going to know how to do all the chaining
09:27:48 [jwatt]
ED: you can do what SVG filters can do with canvas and pixel ops, but the performance will be terrible
09:28:00 [leonardr]
what you really want is something akin to Adobe's PixelBender - http://www.adobe.com/devnet/pixelbender/
09:28:10 [jwatt]
...for WebGL you can do shaders
09:28:26 [jwatt]
...which is more or less filters, if a different way of specing it
09:28:51 [jwatt]
PD: the JS case, is it for wow affects, or putting a simple blur
09:30:05 [jwatt]
PD: the XML namespacing needs to go away
09:30:06 [AlexD]
Don't forget the compositing spec. Those operators map directly to the PDF imaging model as well as Apple's Quartz and play nicer than filters for blending. The filter model is a bit clumsy in hindsight.
09:30:18 [jwatt]
...there are benefits and cons
09:30:36 [jwatt]
...there's the user complexity
09:30:54 [jwatt]
...but then there's the benefits of being able to bring in other things
09:30:58 [jwatt]
...such as metadata
09:31:07 [jwatt]
...XLink should definitely go away
09:31:41 [jwatt]
AG: I think we should deprecate some things, and agree that things should move into CSS or FX now
09:32:00 [jwatt]
...we should consider making it more clear how the spec is architected
09:32:12 [jwatt]
...the way things happen and their timing
09:32:34 [jwatt]
PD: organisation of the spec
09:33:38 [jwatt]
DS: I think we need to think about SVG in three different ways
09:33:51 [jwatt]
...things that are applicable to the web platform as a whole
09:34:12 [jwatt]
...platform features, where SVG is just part of the platform
09:34:25 [jwatt]
...in fact it doesn't need to even just be the Web platform
09:34:35 [jwatt]
...it could be any platform
09:35:08 [jwatt]
... so things like compositing, gradients, filters, styling, transforms - things that affect the way things look and are presented
09:35:19 [jwatt]
...another platform feature is animation
09:35:46 [jwatt]
...things that are moderately complex to implement, but applicable across multiple technologies
09:35:54 [jwatt]
...we should have one model
09:36:09 [jwatt]
...but there's potentially room for more than one syntax
09:36:37 [jwatt]
...and we can extend in SVG where things make sense in SVG when they don't make sense in the platform
09:36:46 [jwatt]
...that's the first part
09:36:55 [jwatt]
...the second is architectural features
09:37:00 [jwatt]
...nesting structure
09:37:02 [jwatt]
...use
09:37:04 [jwatt]
...groups
09:37:12 [jwatt]
...<title>
09:37:31 [jwatt]
...things where their context of their parent mater
09:37:51 [jwatt]
...these things which are specific to SVG
09:38:06 [jwatt]
PD: you don't think HTML would benefit from <use>?
09:38:12 [AlexD]
Also need to consider the dominant architectures for graphics today. IE9 uses H/W acceleration, i.e. GPU. I did have that debate with Jon about filters at the implementers panel. Some H/W acceleration architectures can't get pixels back efficiently. So this also needs consideration. Pixels and pixel manipulation are bad in a vector format IMHO. So what can we leverage from existing GPU capability that will enhance SVG...
09:38:16 [jwatt]
DS: I think that won't happen
09:39:32 [jwatt]
...we have styling attributes in general, as opposed to HTML which doesn't have that so much
09:41:07 [jwatt]
...the third category of SVG is the features of SVG
09:41:34 [jwatt]
...we need to start thinking more about things that SVG should be good at
09:41:41 [jwatt]
...connectors, for example
09:41:55 [jwatt]
...HTML shouldn't have connectors, but SVG should
09:42:46 [jwatt]
LR: WebCGM
09:43:16 [jwatt]
...SVG doesn't have that many of them
09:43:28 [jwatt]
...but these things make it so much easier for authors
09:44:18 [jwatt]
s/of them/of this third category/
09:45:33 [jwatt]
...charts may be one of these features, although that may be going too deep to make primitives for that
09:46:03 [jwatt]
...although the aria guys may disagree, since they really want the semantics
09:46:38 [jwatt]
...anyway, we can look at what is specifically graphical/SVG
09:47:26 [jwatt]
PD: are you including raster and video in "graphical"
09:47:44 [jwatt]
...I don't think you are
09:47:56 [jwatt]
...maybe just "vector" graphical
09:48:12 [jwatt]
LR: I'd hate to see us adding graphing primitives to SVG
09:48:30 [jwatt]
...we should definitely have primitives to enable that to be implemented in SVG
09:48:37 [shepazu]
http://www.w3.org/TR/WD-wwwicn.html
09:48:58 [jwatt]
...but let's keep SVG focused on "vector graphic primitives for the web"
09:52:09 [AlexD]
+1 for Leonard's position
09:55:16 [jwatt]
JW: I'm all for keeping the focus on general purpose primitives that meet a wide range of usecases too
09:55:41 [jwatt]
ED: in SVG 2 I'd like to see us clean up the DOM
09:55:47 [jwatt]
...clean up some of the primitives
09:55:57 [jwatt]
...drop things that are not implemented at all
09:56:11 [jwatt]
...see a focus on maintaining backwards compatibility
09:56:21 [jwatt]
...as long as the content that's out there continues to work
09:56:50 [jwatt]
...SVG fonts don't work
09:56:56 [jwatt]
...vertical text doesn't work
09:57:16 [jwatt]
...animation I think we should revisit
09:57:48 [jwatt]
...thinking about the different solutions for animation
09:57:57 [jwatt]
...thinking about how SMIL interacts with scripting
09:58:18 [jwatt]
...inserting SMIL elements that have been created using script
09:59:10 [jwatt]
...I think we can extend parts of SVG, like with vector affects
09:59:25 [jwatt]
...shape path, like textPath, but for laying out objects
09:59:44 [jwatt]
...layout
09:59:45 [ed]
s/SVG fonts don't work/SVG fonts, some parts are not implemented, we can probably drop some things there/
10:00:14 [AlexD]
We're seeing strong demand for vertical text from Japan - so "vertical text doesn't work" isn't a good comment. We should fix it or provide via HTML/CSS that capability. The world isn't full of westerners you know! You guys trying to kill my SVG video fonts? Hmmph:-) We had graphical object flow in the 1.2 Full work which seems to have all gone into hiatus. Layout is contentious and IMO bad for SVG.
10:00:38 [jwatt]
LR: doesn't layout tread somewhere between XSL-FO and CSS?
10:00:46 [jwatt]
DS: FO is not a Web format
10:01:06 [jwatt]
...and I don't think CSS is interested in constraints based layout
10:01:12 [AlexD]
FO is a W3C spec, so if it's not web, then what's W3C doing defining it...?
10:02:13 [ed]
AlexD: I think we need to rethink vertical text in svg, at least make sure it gets implemented interoperably and that it meets requirements of people asking for it
10:02:21 [jwatt]
...W3C 5-10 years ago, we were siloed into this is HTML and XML
10:02:41 [jwatt]
...we tried to break that down, but browser vendors weren't on board
10:03:04 [jwatt]
...now we're seriously taking a look at all the gaps that have been left by doing things in separate silos
10:03:41 [jwatt]
...but now we are doing a much better job of coordinating between groups
10:04:21 [AlexD]
Interoperability is key, I agree. That's where layout brings you into interoperability hell... Perhaps a sensible way forward is to leverage the HTML5 spec. Subset SVG as the 'efficient SVG' for HTML5 spec and throw out all the things we don't need for stand-alone SVG. Just a thought.
10:04:31 [jwatt]
ED: better integration with HTML and CSS is certainly something we should have as a focus for SVG 2
10:05:23 [ed]
...this includes rethinking foreignObject, and mixing markup
10:05:52 [pdengler]
scribenick : pdenger
10:05:56 [pdengler]
jwatt: Better focus on interoperability between implementations Tests, Suites, Automation
10:06:03 [ed]
scribenick: pdengler
10:06:35 [pdengler]
ed: I second the automation part
10:06:55 [jwatt]
s/implementations Tests, Suites, Automation/implementations by having a push on shared automated test suites/
10:07:00 [pdengler]
pdengler: I agree that interop is absolutely key for SVG being a practial, useful solution
10:07:23 [pdengler]
shepazu: W3C needs to be pushing the automation test suites, and the SVG WG should not have to worry about this
10:08:09 [pdengler]
jwatt: The automated testing is harder than it looks, especially when it comes to collaborating
10:09:08 [shepazu]
s/W3C needs to be pushing the automation test suites, and the SVG WG should not have to worry about this/W3C needs to be pushing the automation test suites, and the SVG WG should work closely along with them
10:09:45 [pdengler]
jwatt: but it is worth it for the sake of content authors having to avoid the headaches
10:14:46 [pdengler]
shepazu: We spent 2 years doing the Tiny 1.2 test suites
10:14:47 [pdengler]
pdengler: Why?
10:15:15 [pdengler]
shepazu: SVG Tiny 1.2 was not written to easily extract testable assertions; other groups have looked more closey from this perspective
10:15:51 [pdengler]
shepazu: SVG WG in large part created the tests which is highly involved.
10:16:28 [AlexD]
More to the point - Tiny 1.2 was run in parallel to the full work and Tiny is shipped in over 700 million phones so it has more traction than desktop SVG has had so far.
10:17:16 [AlexD]
Test review by the WG is incredibly time consuming and not a great use of WG time.
10:17:37 [pdengler]
pdengler: Have we considered test driven development of a spec?
10:17:54 [pdengler]
(all) Yes. We think this will add a lot of value. No new features without sufficient tests
10:20:44 [pdengler]
shepazu: Would love to see Opera, Firefox, IE coming to us with prototypes of features that are not spec'd yet.
10:21:32 [pdengler]
jwatt: It's incredibily valuable to hve that; test should be written as a feature that we trying to spec, whether or not it is independent of the actual engineering
10:24:22 [ed]
(DS elaborates on svg testfest history)
10:26:53 [pdengler]
pdengler: Should the goal be that all UA's pass 100% SVG conformance tests
10:27:04 [AlexD]
Yes.
10:30:02 [AlexD]
e.g. in the printer industry companies like Quality Logic create test suites. There are a number of different levels of test suite. You can ask for certification and that means passing the test suite 100%. We should have a baseline test set that can be endorsed as an interoperable UI. Not as simple as ACID which is obfuscated features, but a general across the board set of features that will give good graphical fidelity for the most common use cases (like graphics
10:30:20 [AlexD]
s/UI/UA/
10:37:01 [pdengler]
jwatt: What does the goal mean in practice
10:39:14 [pdengler]
shepazu: W3C as a standards body does not make conformance tests, we make implementability tests (testing the spec)
10:40:03 [pdengler]
shepazu: The intention is that spec itself can be implemented interoperabiity
10:41:08 [pdengler]
leonardr: How far does that go? Does tha mean that vendor a and vendor b are interoperable for every test?
10:41:52 [pdengler]
shepazu: No; for every given feature we have a test; and as long as two vendors pass any of these specs, it can be considered interoperable and shippable
10:51:43 [pdengler]
jwatt: we started with finit tests; but unfortunately, that level of granularity led to bugs when thinking in the real world composite tests; let's not forget those
10:52:27 [pdengler]
shepazu: This is why I proposed the tiered test that says "this test required feature foo to use"; this would allow for a no-op instead of a fail category
11:31:54 [ed]
ed has joined #svg
11:48:46 [leonardr]
leonardr has joined #svg
13:46:17 [pdengler]
pdengler has joined #svg
13:46:24 [pdengler]
SVG 2.0 scenarios
13:47:00 [pdengler]
shepazu: dynamically scalable images, including a static graphic, or something interactive like an image map
13:47:26 [pdengler]
shepazu: technical drawings, engineering diagrams, floorplans, etc
13:48:02 [pdengler]
shepazu: animated or interactive illstrations (such as mouse over) or the example piston engine
13:48:18 [pdengler]
shepazu: scriptable webapps, whether integrated with HTML or standalone
13:48:21 [ed]
wrt to the discussion on svg fonts, some examples/use-cases here: http://dev.opera.com/articles/view/seven-web-fonts-showcases
13:48:30 [pdengler]
shepazu: re-usable component graphics
13:48:41 [pdengler]
shepazu: games
13:49:21 [pdengler]
shepazu: things we should look at as features : connectors, parameters and improve the DOM, and more specifially a shared API with <canvas>
13:49:47 [pdengler]
shepazu: and seriously consider a math engine and/or physics engine
13:51:27 [pdengler]
anthony: the ability to author UI's for standalone apps and to control audio/video etc
13:51:40 [pdengler]
anthony: star wars credit text effect
13:52:37 [pdengler]
anthony: psuedo 3d (2.5D)
13:53:59 [pdengler]
anthony: basic animation on text and glyphs (like the a glyph on fire)
13:56:47 [pdengler]
pdengler: A developer wishes to use SVG as an image interleaved thorughout web pages where scalability or image size (where possible) can improve
13:58:00 [pdengler]
pdengler: A Developer wishes to create a richer, more graphic intensive webapps where HTML does not suite the needs well to creating the graphic experience, using a comomn programming model or framework which increases the productivity of the developer, user experience and satisfcation improve, and is interoperable
13:58:28 [pdengler]
pdengler: A web site hosts interactive vector graphic diagrams mixed with HTML such as org charts, calendars, graphs and maps
13:58:35 [pdengler]
pdengler: games like on OneMoreLevel
14:02:49 [pdengler]
jwatt: Dynamic and interactive display of information :educational material, data visualization (graphing, orgcharts), documentation
14:04:09 [pdengler]
ed: User interfaces
14:05:49 [pdengler]
ed: audio/video : educational material, tv station
14:07:03 [pdengler]
ed: progressive rendering and streaming : for a long running animation, and discard portions as they are utilized
14:09:39 [pdengler]
ed: advanced text effects (change fonts dynamically)
14:12:44 [shepazu]
http://www.fiestagrill.us/FGname.jpg
14:14:41 [pdengler]
http://ie.microsoft.com/testdrive/Performance/12ScrollingText/Default.xhtml
14:28:07 [f1lt3r]
f1lt3r has joined #svg
15:13:51 [Zakim]
ed, you asked to be reminded at this time to take a break
15:14:37 [ed]
Zakim, remind me in 2 hours that we should stop talking
15:14:39 [Zakim]
ok, ed
15:55:11 [ed]
rrsagent, end telcon
15:55:11 [RRSAgent]
I'm logging. I don't understand 'end telcon', ed. Try /msg RRSAgent help
15:55:34 [ed]
trackbot, end telcon
15:55:34 [trackbot]
Zakim, list attendees
15:55:34 [Zakim]
sorry, trackbot, I don't know what conference this is
15:55:35 [trackbot]
RRSAgent, please draft minutes
15:55:35 [RRSAgent]
I have made the request to generate http://www.w3.org/2010/05/26-svg-minutes.html trackbot
15:55:36 [trackbot]
RRSAgent, bye
15:55:36 [RRSAgent]
I see no action items