An open source license is an idea that I can't speak to (I have no authority to make those sorts of decisions), but your comments are well noted.
I CAN speak about performance and native implementation though. Performance would indeed be increased if we natively implemented dSVG, but we chose to instead abide by the standards and ensure that dSVG worked on other SVG viewers. As I said earlier in the week on the svg-developers newsgroup on Yahoo, Corel's mantra is standards, standards, standards. Interoperability, interoperability, interoperability. The Corel SVG Viewer abides by the SVG spec exactly. There are no extensions. The only non-standard thing we implemented are some of the SVGWindow object methods (like getURL(), parseXML(), alert(), etc) which are really needed, already in other SVG viewers and will be in the SVG 1.2 spec anyway.
Natively implementing dSVG would likely be praised by some, but greatly criticized by others. That said, I am certain that the performance of dSVG can be improved in its script implementation by some re-architecting of some key concepts. You will definitely see big improvements in the future.
I don't think that dSVG really competes that much with RCC and Live Templates. Those two proposals are about allowing the author to better handle arbitrary XML via script or XSLT--they are both quite elegant. dSVG, on the other hand, is a proposal to standardize the sort of markup that a lot of people actually need right now, to prevent everyone from having to reinvent the wheel and implement things themselves. So while UI controls could be implemented with RCC and Live Templates, we would prefer that UI markup be a standard as soon as possible, so that they can be natively implemented ASAP. Plus having a dozen different markups and implementations for UI controls doesn't make the SVG standard look good (IMHO). So long as the UI controls can be completely customizable, there's no need for numerous variations on the markup. Standards are good.
And dSVG's behavior elements are an attempt to get away from script--so that authoring tools can more easily author interactive SVG, as well as edit the interactive SVG produced by other authoring tools. Plus, markup could be implemented natively on small devices, so that they might not need a script engine at all--which is very appealing. The fact that something CAN be done with script, should never be an excuse not to invent a standard way of doing it with markup.
You make some good points. It is true that in some cases, programming via XML is more verbose, however for other cases it is less verbose, since the dSVG behaviour elements are generally at a higher level. Of course, the same thing could have been accomplished with a library of script functions--but you can't data-map them and they could never become part of a standard.
Currently, we need ECMAScript to be the "glue", as you pointed out. But the intent behind dSVG has always been that it would lead to standard markup, which could then be implemented natively. Being able to develop an entire Web application without the need for a script engine is an appealing notion.
Thanks for the feedback. If UI markup were part of a standard and thus natively implemented, then I think skins should be optional, and the viewer decides how to display the widgets, so that there's less data to transfer. Since we implemented with script, all we could do for now is supply default skins. CSS is indeed powerful, but it requires structure to act upon, so the SVG markup that defines the appearance must be provided somewhere. These UI controls could be used instead of XForms, when you don't want to have to pretend you have a form (faking instanceData) when you really don't. But it could also be used in conjunction with XForms. At least, that's the idea. XForms is great for data collection, validation and submission, but if all I want is a button that causes some attributes or cdata to change, I should simply be able to associate a simple behaviour element to a simple UI element and that's it.
Who would use it? People that want to create "data-driven" web apps, be they developers or designers. HTML is not much of an option. XHTML would be better, but neither has enough UI controls. Writing your own code to create robust, flexible, stable UI controls that interact properly together takes a long time. People shouldn't have to do that. UI controls and behaviours via markup allows for rapid application development.
But maybe it's all not simple enough, as you say. I'll keep that in mind as we continue to improve this.
It's XML markup, therefore it can be data-mapped and transformed via XSLT.
It's easier for an authoring tool to create markup (which the author can customize) than to create script.
It's more high-level than DOM methods, providing a more direct linkage between the syntax and the intent of the author. So it's more intuitive to non-developers than script, thus allowing designers to create web apps all by themselves.
Because it's markup, it (or something like it) has the potential to become a standard one day and thus become natively implemented. This would allow SVG on small devices to still have excellent interactivity without needing a script engine, which typically takes up half of the footprint (aside from being slow).
Markup is guaranteed to be interoperable on the authoring side, while scripting is not.
Yup, and there's plenty more reasons why SVG is often preferred over Flash. It's a standard, for one thing. A lot of people like standards. Our dSVG has been proposed to the SVG Working Group, so we hope that it will lead to a standard also. Standards are good.
It's also easily data-driven since it's XML. Flash is good for multi-media, but I (personally) doubt it will ever be a major player in the data-driven graphics/apps space. The idea of creating a pure XML solution, from beginning to end, is very appealing.
The dSVG code itself is still part of our IP, so unfortunately I can't show it to you (sorry). But if dSVG had instead been implemented natively in the SVG Viewer (which would not have been proper), I don't think most would dispute it's code being unreleased. I should point out, however, that the reason the script is obfuscated is not just to protect IP, it's also because it's actually much faster that way, since the strings are smaller. Really, I was actually quite shocked at just how much faster it is.
As for sample applications built using CSGS, you can find lots of them at www.corel.com/smartgraphics/resources.
Wow, I've never been called a cowboy developer before... I kinda like it.:)
To respond to your concerns, however, let me say that we could have kept this markup proprietary forever, choosing to use it to distinguish our authoring tools from the others, but instead we proposed it to the SVG Working Group because we want it to become a standard that everyone benefits from. That should be considered a good thing.
As for your statement that the last person to design a markup language for programming should be a programmer... are you serious?
As for my not having a clue what users want, I actually think I did a pretty good job at talking with designers to make sure I designed something they would understand. That's why its procedural, for instance instead of functional like XSLT. If you think I made some bad design choices, please tell me. And I didn't create the spec "entirely" by myself. Others on the teams have had plenty of opportunity to influence it, and my colleague (who did more coding than me) and I routinely bounced ideas of of each other all the time. Regardless, more developers and designers looking at it and evaluating would be a very good thing. Thus the reason for my posting to Slashdot.
It's XML markup, therefore it can be data-mapped and transformed via XSLT.
It's easier for an authoring tool to create markup (which the author can customize) than to create script.
It's more high-level than DOM methods, providing a more direct linkage between the syntax and the intent of the author. So it's more intuitive to non-developers than script, thus allowing designers to create web apps all by themselves.
Because it's markup, it (or something like it) has the potential to become a standard one day and thus become natively implemented. This would allow SVG on small devices to still have excellent interactivity without needing a script engine, which typically takes up half of the footprint (aside from being slow).
Markup is guaranteed to be interoperable on the authoring side, while scripting is not.
For anyone scared to death by that EULA (I've been assured it's harmless), here is a couple of checkboxes that change the data of a text element. More examples to come.
Some people think SVG and Flash directly compete, and others say no. But let's compare them for the case of creating data-driven applications. If you think that you don't have to code in Flash, then you must not have used it. It uses ActionScript, which is like a stripped-down ECMAScript (I think). But it's script. They have a UI for generating it, but it's mainly a succession of dropdown menus to finally insert an 'if' statment. So you're not freed from the need of actually knowing how to program or anything. But even if you did want to use a proprietary binary standard to create an enterprise-class data-driven application, can you and should you? Macromedia recently has tried to enter the Enterprise space to do this, but the idea of using a proprietary solution does not sit well with everyone. Especially when the alternative is to use a complete XML solution from beginning to end. Data-driven graphics and data-driven applications are just now starting to take off. And most of them are using SVG because it's an XML-language--thus you can data-map it easily with XSLT. Many argue that while SVG may be able to compete in the multi-media space, that's not where its strength lies. It's strength is in the visualization of data.
I know it's not open-source, but we HAVE proposed the spec to the SVG Working Group for consideration. I want it to LEAD to a standard, after lots of feedback and collaborative discussion, not to BE the standard as-is. I'm only one developer--what are the odds that I thought of everything? Zilch.
Hmm, I know we've had the CSV working with Mozilla on W2K before... maybe not with Mozilla 1.4? I'll look into it. As for a Linux version, NOTHING is ever out of the question. It's all based on demand right now--we have a ton of tasks to do and each one of them has a priority. If a lot of people want CSV on Linux, then that will bump up the priority.
Hmm. That's a good idea. It's actually my fault, really. They asked me if I could post just the spec and I said that the spec currently linked to the slides in the test suite and that I thought most people would like to actually play around with it. So they said, okay, but we'll need a EULA then. And I said, okay, and then went off to my SVG Open conference. So yes, I'll look into just posting the spec without all that legaleze stuff. It's the weekend, though, so I doubt it would happen until Monday.
The final output runs in any standard SVG viewer, and some of them run on Mac and Linux (although not Corel's SVG Viewer yet, but only because we're concentrating on finishing up implementing the full SVG spec first). But yeah, CSGS is currently a Windows only product, and again, just because of limited resources right now--if there's enough of a market for selling CSGS for other platforms, I'm sure that would speed up our supporting them. If you would actually buy it if only it supported Linux or Max, please tell me!
Yeah, I know... lawyers. What can you do. I'm not looking for beta testers though--I'm more interested in what you all think from more of a philosophical perspective. Does programming via markup make sense? Might this sort of thing grow into a real, honest-to-God, full-featured programming language one day? Is the fundamental design sound? That sort of thing.
dSVG is NOT a spec being proposed by the W3C. It's something we came up with ourselves for our product, and then proposed to the SVG Working Group. The concept of having "standard" markup for UI controls has been around a long time, but it hasn't happened yet. Maybe we're not asking enough people if it's what they really want or not. And if we want it, does it belong in SVG or should it be something larger and more generic in its own spec? And the idea of using XML for procedural programming is pretty new, I think. At least I had never found another example of it. Maybe someone else knows of one though.
Regardless, I strongly believe in asking communities what they want rather than telling them what they want, and I also strongly believe in getting ideas and constructive feedback from people outside of the SVG-world. I couldn't think of a better forum than Slashdot to solicit that type of feedback.
Wow, this actually got posted. Cool. Let me first say that the dSVG 1.1 spec is still evolving. There's lots of room for improvements. For instance, there's an 'if' element, but no 'elseif' or 'else' elements yet. Those are obviously needed. I originally thought that a DTD could not (or should not) define an element as being dependent upon a sibling, but after talking with some XML experts at the SVG Open conference in Vancouver this past week, I see now that I was wrong. Another needed feature is some kind of a fallThrough="true|false" attribute for the 'case' elements within a 'switch' element--mimicking the 'break' statement but in a more XML-ish way.
One huge area for improvements is in the design of the skins. It seemed like a good idea at the time, but I now see that it has limitations both for performance and for the creation of custom UI controls. More on that in a separate comment...
The fact that dSVG is implemented with script is, for now, a good thing because it allows us to make changes to the spec without the viewer, since the implementation gets passed along with the content. And for previously written content, the Corel Smart Graphics Studio (CGSG) IDE will automatically convert from the old version of dSVG to the new version (via XSLT).
I have a big list of ideas for improvements, but it's back at home and I'm still in Vancouver for a few more days attending meeting (so I apologize in advance if I am not always responding in a prompt manner). I'm really interested to see what other developers think of the spec thus far and how it could be improved.
Slashdot Mirror
An open source license is an idea that I can't speak to (I have no authority to make those sorts of decisions), but your comments are well noted.
I CAN speak about performance and native implementation though. Performance would indeed be increased if we natively implemented dSVG, but we chose to instead abide by the standards and ensure that dSVG worked on other SVG viewers. As I said earlier in the week on the svg-developers newsgroup on Yahoo, Corel's mantra is standards, standards, standards. Interoperability, interoperability, interoperability. The Corel SVG Viewer abides by the SVG spec exactly. There are no extensions. The only non-standard thing we implemented are some of the SVGWindow object methods (like getURL(), parseXML(), alert(), etc) which are really needed, already in other SVG viewers and will be in the SVG 1.2 spec anyway.
Natively implementing dSVG would likely be praised by some, but greatly criticized by others. That said, I am certain that the performance of dSVG can be improved in its script implementation by some re-architecting of some key concepts. You will definitely see big improvements in the future.
I don't think that dSVG really competes that much with RCC and Live Templates. Those two proposals are about allowing the author to better handle arbitrary XML via script or XSLT--they are both quite elegant. dSVG, on the other hand, is a proposal to standardize the sort of markup that a lot of people actually need right now, to prevent everyone from having to reinvent the wheel and implement things themselves. So while UI controls could be implemented with RCC and Live Templates, we would prefer that UI markup be a standard as soon as possible, so that they can be natively implemented ASAP. Plus having a dozen different markups and implementations for UI controls doesn't make the SVG standard look good (IMHO). So long as the UI controls can be completely customizable, there's no need for numerous variations on the markup. Standards are good.
And dSVG's behavior elements are an attempt to get away from script--so that authoring tools can more easily author interactive SVG, as well as edit the interactive SVG produced by other authoring tools. Plus, markup could be implemented natively on small devices, so that they might not need a script engine at all--which is very appealing. The fact that something CAN be done with script, should never be an excuse not to invent a standard way of doing it with markup.
You make some good points. It is true that in some cases, programming via XML is more verbose, however for other cases it is less verbose, since the dSVG behaviour elements are generally at a higher level. Of course, the same thing could have been accomplished with a library of script functions--but you can't data-map them and they could never become part of a standard.
Currently, we need ECMAScript to be the "glue", as you pointed out. But the intent behind dSVG has always been that it would lead to standard markup, which could then be implemented natively. Being able to develop an entire Web application without the need for a script engine is an appealing notion.
Thanks again for your feedback.
Thanks for the feedback. If UI markup were part of a standard and thus natively implemented, then I think skins should be optional, and the viewer decides how to display the widgets, so that there's less data to transfer. Since we implemented with script, all we could do for now is supply default skins. CSS is indeed powerful, but it requires structure to act upon, so the SVG markup that defines the appearance must be provided somewhere. These UI controls could be used instead of XForms, when you don't want to have to pretend you have a form (faking instanceData) when you really don't. But it could also be used in conjunction with XForms. At least, that's the idea. XForms is great for data collection, validation and submission, but if all I want is a button that causes some attributes or cdata to change, I should simply be able to associate a simple behaviour element to a simple UI element and that's it.
Who would use it? People that want to create "data-driven" web apps, be they developers or designers. HTML is not much of an option. XHTML would be better, but neither has enough UI controls. Writing your own code to create robust, flexible, stable UI controls that interact properly together takes a long time. People shouldn't have to do that. UI controls and behaviours via markup allows for rapid application development.
But maybe it's all not simple enough, as you say. I'll keep that in mind as we continue to improve this.
Reposting this from a previous comment...
It's XML markup, therefore it can be data-mapped and transformed via XSLT.
It's easier for an authoring tool to create markup (which the author can customize) than to create script.
It's more high-level than DOM methods, providing a more direct linkage between the syntax and the intent of the author. So it's more intuitive to non-developers than script, thus allowing designers to create web apps all by themselves.
Because it's markup, it (or something like it) has the potential to become a standard one day and thus become natively implemented. This would allow SVG on small devices to still have excellent interactivity without needing a script engine, which typically takes up half of the footprint (aside from being slow).
Markup is guaranteed to be interoperable on the authoring side, while scripting is not.
Yup, and there's plenty more reasons why SVG is often preferred over Flash. It's a standard, for one thing. A lot of people like standards. Our dSVG has been proposed to the SVG Working Group, so we hope that it will lead to a standard also. Standards are good.
It's also easily data-driven since it's XML. Flash is good for multi-media, but I (personally) doubt it will ever be a major player in the data-driven graphics/apps space. The idea of creating a pure XML solution, from beginning to end, is very appealing.
Thanks for your input. We need that sort of feedback. I'll be sure to pass this on to the higher-ups.
The dSVG code itself is still part of our IP, so unfortunately I can't show it to you (sorry). But if dSVG had instead been implemented natively in the SVG Viewer (which would not have been proper), I don't think most would dispute it's code being unreleased. I should point out, however, that the reason the script is obfuscated is not just to protect IP, it's also because it's actually much faster that way, since the strings are smaller. Really, I was actually quite shocked at just how much faster it is.
As for sample applications built using CSGS, you can find lots of them at www.corel.com/smartgraphics/resources.
Wow, I've never been called a cowboy developer before... I kinda like it. :)
To respond to your concerns, however, let me say that we could have kept this markup proprietary forever, choosing to use it to distinguish our authoring tools from the others, but instead we proposed it to the SVG Working Group because we want it to become a standard that everyone benefits from. That should be considered a good thing.
As for your statement that the last person to design a markup language for programming should be a programmer... are you serious?
As for my not having a clue what users want, I actually think I did a pretty good job at talking with designers to make sure I designed something they would understand. That's why its procedural, for instance instead of functional like XSLT. If you think I made some bad design choices, please tell me. And I didn't create the spec "entirely" by myself. Others on the teams have had plenty of opportunity to influence it, and my colleague (who did more coding than me) and I routinely bounced ideas of of each other all the time. Regardless, more developers and designers looking at it and evaluating would be a very good thing. Thus the reason for my posting to Slashdot.
It's XML markup, therefore it can be data-mapped and transformed via XSLT.
It's easier for an authoring tool to create markup (which the author can customize) than to create script.
It's more high-level than DOM methods, providing a more direct linkage between the syntax and the intent of the author. So it's more intuitive to non-developers than script, thus allowing designers to create web apps all by themselves.
Because it's markup, it (or something like it) has the potential to become a standard one day and thus become natively implemented. This would allow SVG on small devices to still have excellent interactivity without needing a script engine, which typically takes up half of the footprint (aside from being slow).
Markup is guaranteed to be interoperable on the authoring side, while scripting is not.
Dunno why that semicolon is appearing before the button element...
G 11" xmlns:xlink="http://www.w3.org/1999/xlink" height="410px" width="744px" onload="init(evt)" viewBox="0 0 744 410">
t on" autoScale="true" disabled="false" selected="false" toggle="false" height="18" width="100" y="100" x="50" label="setTransform" id="dsvgUniqueID_0">
<svg xmlns:dsvg="http://www.corel.com/schemas/2002/dSV
<script type="text/ecmascript" xlink:href="dsvg11/dSVG.js"/>
<script type="text/ecmascript" xlink:href="dsvg11/baseUI.js"/>
<script type="text/ecmascript" xlink:href="dsvg11/constraint.js"/>
<script type="text/ecmascript" xlink:href="dsvg11/button.js"/>
<script type="text/ecmascript" xlink:href="dsvg11/setTransform.js"/>
<dsvg:button xlink:href="dsvg11/skinButton_Windows.svg#skinBut
<dsvg:setTransform cy="175" cx="300" rotate="30" vAlign="middle" hAlign="middle" absolute="false" elementID="shape1" id="dsvgUniqueID_1"/>
</dsvg:button>
<rect height="50" width="100" y="150" x="250" stroke-width="5" stroke="darkblue" fill="#5f86B1" id="shape1"/>
</svg>
For anyone scared to death by that EULA (I've been assured it's harmless), here is a couple of checkboxes that change the data of a text element. More examples to come.
G 11" xmlns:xlink="http://www.w3.org/1999/xlink" height="410px" width="744px" onload="init(evt)" viewBox="0 0 744 410">
h eckBox" autoScale="true" disabled="false" selected="false" height="12" width="12" y="70" x="50" label="Check Box 1" id="checkBox1">h eckBox" autoScale="true" disabled="false" selected="true" height="12" width="12" y="120" x="50" label="Check Box 2" id="checkBox2">
Gord
<svg xmlns:dsvg="http://www.corel.com/schemas/2002/dSV
<script type="text/ecmascript" xlink:href="dsvg11/dSVG.js"/>
<script type="text/ecmascript" xlink:href="dsvg11/baseUI.js"/>
<script type="text/ecmascript" xlink:href="dsvg11/constraint.js"/>
<script type="text/ecmascript" xlink:href="dsvg11/button.js"/>
<script type="text/ecmascript" xlink:href="dsvg11/setData.js"/>
<dsvg:checkBox toggle="true" xlink:href="dsvg11/skinCheckBox_Default.svg#skinC
<dsvg:setData value="Sample of setting data." elementID="checkBoxLabel" id="dsvgUniqueID_8"/>
</dsvg:checkBox>
<text y="80" x="150" fill="green" id="checkBoxLabel">label</text>
<dsvg:checkBox toggle="true" xlink:href="dsvg11/skinCheckBox_Default.svg#skinC
<dsvg:setData value="Sample of setting data." elementID="checkBoxLabel2" id="dsvgUniqueID_9"/>
</dsvg:checkBox>
<text y="130" x="150" fill="green" id="checkBoxLabel2">label</text>
</svg&g t;
Some people think SVG and Flash directly compete, and others say no. But let's compare them for the case of creating data-driven applications. If you think that you don't have to code in Flash, then you must not have used it. It uses ActionScript, which is like a stripped-down ECMAScript (I think). But it's script. They have a UI for generating it, but it's mainly a succession of dropdown menus to finally insert an 'if' statment. So you're not freed from the need of actually knowing how to program or anything. But even if you did want to use a proprietary binary standard to create an enterprise-class data-driven application, can you and should you? Macromedia recently has tried to enter the Enterprise space to do this, but the idea of using a proprietary solution does not sit well with everyone. Especially when the alternative is to use a complete XML solution from beginning to end. Data-driven graphics and data-driven applications are just now starting to take off. And most of them are using SVG because it's an XML-language--thus you can data-map it easily with XSLT. Many argue that while SVG may be able to compete in the multi-media space, that's not where its strength lies. It's strength is in the visualization of data.
Umm... yeah. Good point. Lemme see what I can do here.
Thanks! I'll look into that one.
I know it's not open-source, but we HAVE proposed the spec to the SVG Working Group for consideration. I want it to LEAD to a standard, after lots of feedback and collaborative discussion, not to BE the standard as-is. I'm only one developer--what are the odds that I thought of everything? Zilch.
Hmm, I know we've had the CSV working with Mozilla on W2K before... maybe not with Mozilla 1.4? I'll look into it. As for a Linux version, NOTHING is ever out of the question. It's all based on demand right now--we have a ton of tasks to do and each one of them has a priority. If a lot of people want CSV on Linux, then that will bump up the priority.
Yeah, I understand. Sorry 'bout that. I'll try to get just the spec published, without the script and EULA. Hopefully on Monday.
Hmm. That's a good idea. It's actually my fault, really. They asked me if I could post just the spec and I said that the spec currently linked to the slides in the test suite and that I thought most people would like to actually play around with it. So they said, okay, but we'll need a EULA then. And I said, okay, and then went off to my SVG Open conference. So yes, I'll look into just posting the spec without all that legaleze stuff. It's the weekend, though, so I doubt it would happen until Monday.
The final output runs in any standard SVG viewer, and some of them run on Mac and Linux (although not Corel's SVG Viewer yet, but only because we're concentrating on finishing up implementing the full SVG spec first). But yeah, CSGS is currently a Windows only product, and again, just because of limited resources right now--if there's enough of a market for selling CSGS for other platforms, I'm sure that would speed up our supporting them. If you would actually buy it if only it supported Linux or Max, please tell me!
Yeah, I know... lawyers. What can you do. I'm not looking for beta testers though--I'm more interested in what you all think from more of a philosophical perspective. Does programming via markup make sense? Might this sort of thing grow into a real, honest-to-God, full-featured programming language one day? Is the fundamental design sound? That sort of thing.
dSVG is NOT a spec being proposed by the W3C. It's something we came up with ourselves for our product, and then proposed to the SVG Working Group. The concept of having "standard" markup for UI controls has been around a long time, but it hasn't happened yet. Maybe we're not asking enough people if it's what they really want or not. And if we want it, does it belong in SVG or should it be something larger and more generic in its own spec? And the idea of using XML for procedural programming is pretty new, I think. At least I had never found another example of it. Maybe someone else knows of one though. Regardless, I strongly believe in asking communities what they want rather than telling them what they want, and I also strongly believe in getting ideas and constructive feedback from people outside of the SVG-world. I couldn't think of a better forum than Slashdot to solicit that type of feedback.
You can find some demo apps at www.corel.com/smartgraphics/resources. As for apps created by customers, I don't know.
Wow, this actually got posted. Cool. Let me first say that the dSVG 1.1 spec is still evolving. There's lots of room for improvements. For instance, there's an 'if' element, but no 'elseif' or 'else' elements yet. Those are obviously needed. I originally thought that a DTD could not (or should not) define an element as being dependent upon a sibling, but after talking with some XML experts at the SVG Open conference in Vancouver this past week, I see now that I was wrong. Another needed feature is some kind of a fallThrough="true|false" attribute for the 'case' elements within a 'switch' element--mimicking the 'break' statement but in a more XML-ish way.
One huge area for improvements is in the design of the skins. It seemed like a good idea at the time, but I now see that it has limitations both for performance and for the creation of custom UI controls. More on that in a separate comment...
The fact that dSVG is implemented with script is, for now, a good thing because it allows us to make changes to the spec without the viewer, since the implementation gets passed along with the content. And for previously written content, the Corel Smart Graphics Studio (CGSG) IDE will automatically convert from the old version of dSVG to the new version (via XSLT).
I have a big list of ideas for improvements, but it's back at home and I'm still in Vancouver for a few more days attending meeting (so I apologize in advance if I am not always responding in a prompt manner). I'm really interested to see what other developers think of the spec thus far and how it could be improved.