dSVG - A New Kind of Programming?

Gord Bowman writes "For anyone familiar with XML and, specifically, with SVG (Scalable Vector Graphics), you may be aware that SVG is increasingly being used for the creation of data-driven Web applications. But everyone has been doing so by handcoding script and/or XSLT, without the benefit of an IDE to help. Seeing such a need for a tool, my company (Corel) set about creating one." and 'lo, dSVG was born. Gord Bowman is the lead developer of dSVG and would like you to take a look at the dSVG specs (you can find the link, in the full article) and offer your comments.

"It quickly became apparent that while getting a grasp of XSLT is difficult and time-consuming, even more time-consuming was all the scripting it took to create the level of interactivity required on the client via script. Thus we set about creating a library of generic script functions that would assist developers in creating their Web apps. But it didn't take long to realize that this was no good--you can't data-map and transform (via XSLT) functions like you can markup. And, unlike markup, it's much more difficult to auto-generate and customize script via an authoring tool. So I set about designing an XML markup language, implemented with script (so as to work in any SVG viewer), which would describe UI controls and behaviours, so as to facilitate the creation of SVG-based Web applications.

It was a programmer's dream. I was essentially being paid to develop a new kind of programming language. One that, like XSLT, is XML-based but is more procedural in nature and thus easier for the average developer to grasp. It's also easier for non-developers to grasp it, thus bringing SVG and application development to a whole new class of user. A year later, dSVG (Dynamic SVG) was unveiled to the public as part of the Corel Smart Graphics Studio. And as of yesterday, the full dSVG 1.1 Specification and Test Suite became available for download.

The UI controls were designed to allow complete customization of appearance, and to allow for use with forms without being tied to a forms-specific model. The behaviors were designed to be generic and higher level than DOM methods, so as to be more intuitive to non-developers. The resulting markup language allows data-driven Web applications to be created with little or no need for scripting.

While script is very useful and powerful, markup has many advantages:

- markup is more easily understood by non-developers
- markup can be easily data-mapped and transformed using XSLT
- markup can be easily generated via an authoring tool and customized by the author
- markup is semantically meaningful, promoting interoperability on the authoring side
- markup can be standardized, thus helping the adoption of SVG

dSVG was implemented with script so as to work in different SVG Viewers. However, Corel has proposed dSVG to the SVG Working Group in the hopes that through a collaborative effort, dSVG will lead to the eventual creation of standard markup for UI controls and behaviors. These could then be natively implemented, bringing about even more advantages:

- faster
- less data to transfer
- less need for a script engine on small devices (which can take up a significant part of the footprint)

The dSVG 1.1 spec and test suite was posted for download with the goal of allowing the developers and non-developers to experiment with the markup and to provide feedback. This feedback will help me to improve upon dSVG and will also help the SVG Working Group to better assess how the developer community feels about such standard markup being added to the spec for the purpose of developing SVG-based Web applications.

I hope you will take the time to read through the dSVG spec, try out the test suite, and perhaps even create some of your own content. As the creator, I am obviously passionate and excited about dSVG. And having seen how quickly even non-developers can create Web apps, I feel certain that XML-based programming makes sense and is the way of the future. But being a long-time reader of Slashdot, I would love to hear what the Slashdot community thinks. dSVG may not lead to world peace, but I think it has the potential to change the fundamental way in which Web applications are created.

I look forward to hearing your comments.

Sincerely,

Gord Bowman
Lead Developer, Corel Corporation"

Goodbye RFC, hello Slashdot

[Psychic Burrito]

Shouldn't new standards be introduced using RFCs? I'm not sure if it's a good trend when they are presented first on Slashdot...

Windows only?

[Tumbleweed]

Okay, so when are the Mac OS X and Linux versions due out? This is a pretty amusing situation - a development studio/language for something that isn't viewable without a plugin on its only supported OS?

As much as this interests me, forget it!

[Jack William Bell]

There is no way I am going to 'read and understand' all that legal language. I would rather create my own competing specification than do that.

So, either release it under a license I can understand (one consisting of ten or less paragraphs) or forget it!

Adopting SVG

[HisMother]

SVG is a Good Thing, and it would be fantastic if it had broader browser support. Is anybody sufficiently familiar with the dark corners of the standard to explain why we don't see more implementations? Would it really be so hard for Adobe to update their Linux implementation to work with current browsers? Why isn't Mozilla/SVG farther along?

Re:Sounds great...

[bwt]

I agree completely that browsers need to support SVG, and until this is more advanced, tools like the one in this article are getting ahead of things (not that that's necessarily bad). People should vote for Mozilla bug 122092: "Enable SVG support". Ultimately, this needs to be done without plugins -- its really just another image format.

The Konqueror browser seems to have a push to get SVG going too: KSVG [kde.org], but it has a way to go ("Release 0.1 pending").

There are a good set of SVG resources [protocol7.com] for Linux. The Apache Jakarta projects java SVG viewer, Batik is probably the farthest along.

Re:435098734912

[HisMother]

Lots of little things that add up:

• XML is more structured than INI files, tags can be nested, and can have attributes
• Several standard APIs for parsing, with multiple robust implementations
• Tools. Graphical XML editors and viewers, browser support, etc.
• XSLT is a nice scripting language for querying, formatting, rearranging, extracting, and building XML.
• Books and example code. There's a wealth of information on ways to use XML out there now.
• Critical mass. Enough people are using XML that you can exchange XML data with other people and expect them to know how to deal with it; and this large mass of applications means that the number of available tools, books, and resources just keeps growing.

You could compare XML to something like KIF or even XML's own parent SGML and ask "Why XML? Why now?" Critical mass, I think, is most important, more than anything else. You could do all the same things with another file format -- but you wouldn't have the range of tools, APIs, and features to choose from.

Re:Can you please post the spec by itself?

[tmoertel]

So yes, I'll look into just posting the spec without all that legaleze stuff.

Excellent! Thanks for being cool about this.

It's the weekend, though, so I doubt it would happen until Monday.

Can you give us anything right now? Monday, I'll be working, but today I can look at your spec. I'm sure a lot of other Slashdot readers are in the same boat. Also, on Monday, your article will be long gone from the Slashdot front page, and so you might want to make better use of this opportunity to introduce readers to the meat of dSVG.

Even if you must wait until Monday to get the OK from the lawyers to post the spec, certainly you can give us something now to give us a feel of dSVG.

How about posting or linking to a few snippets of dSVG code? (Actually, I'm surprised that you didn't include a snippet or two in your original announcement.) Most programmers reading this article will want to see what dSVG code looks like. Throw us a bone!

Cheers,
Tom

Re:Windows only?

[appleLaserWriter]

Mr Bowman,

I represent a growing provider of diverse Internet services. We have determined that the Linux platform is by far the most cost effective platform for new projects. Because we have selected Linux as the standard server platform, we find that Apple's Unix-based OS X platform is ideal for desktop use by designers and engineers who produce our new projects. Although we consider tools that require the Windows platform, we are most seriously interested in products that support OS X or Linux. In our experience, many other growing internet ventures hold a similar opinion.

Flash vs. SVG

[Gord Bowman]

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.

Using SVG in real world apps ...

[vi-rocks]

.. we are and its fantastic. First of all, all our clients are running either Windows (98 to XP) or Mac OS X .. Adobe's plug-in is working just fine. We made a small modification to the Apache config file and feed our SVG files through the PHP interpreter first -- with PHP code embedded in the SVG file. Much of the data begin display on our clients SVG drawings are dynamic and sourced from a MySQL database. As the database is updated, the SVG drawings and figures change automatically. Saves a ton of work.

Re:Goodbye RFC, hello Slashdot

[russcoon]

Gord,

Using XML for procedural programing isn't new. ANT comes to mind. Unfortunantly it turns out it's a really crappy language to program in (overly verbose, etc...). It does, however, make a decent glue language for putting down the declarative portions of a GUI.

As for the usage of XML-ish markup to define widgets, that's also not really very new. XUL, GLADE, netWindows (my project) all come to mind. The problem is tying them to data and programatic constructs. It's nice to see you're taking a similar tack with your wiget set as we are, however I tend to think that the minute you start writing standards around your toolkit, you only decrease your room to improve in the future. The community, i hate to say it, really doesn't know what they want which is why innovation is so powerful. It takes independent thought and originality to come up with someone else's old hat, and it seems you have that in spades. The trick is to not imagine that the community at large is imbued with the same qualities. The world at large doesn't care. You have to reach people with a need for what you want to do. The are the only ones that really matter.

A small dev team of people that grok what you're talking about and are interested in assisting you in making things better is usually going to yeild significantly better results than throwing something to the winding and seeing what takes off. In the worst case, you've satisfied the needs of the people that have needs in the first place, which isn't a bad place to be (although it can surely be obscure).

Anyway, I'd like to talk with you more about your toolkit. Your email addr isn't in your profile, so you can reach me at [e-mail].

Regards.

Check out xpserver, a generalized dSVG

[jonsmirl]

http://xpserver.mozdev.org/ xpserver is complicated and not finished, although there is a group in India actively working on it.

From the web site: mod_PX7 then uses XPCOM to load and run the components. The components can be chained using SAX-like events. For example a database component can do a query. The output from the db component is expected to be in XML. This XML can be sent to the browser or fed into another component. For example, an XSLT style sheet. The output from the stylesheet can then go to the browser or be fed into yet another component such as FOP for PDF generation or xmlch to generate a 3D chart using GDChart.

You can think of this as starting with an XML file. The XML file is then transformed by various processes into other intermediate XML files. The final transform may be to SVG, XML, PDF, JPEG, etc. In reality the intermediate files don't exist and the stages are chained together via SAX events.

Transformation stages can be written in XSLT, C or Javascript. Some of the XSLT/Javascript transformation stages were writen to detect browser capabilities, if the browser is capable the stage runs in the browser instead of the server.

If you think about this to the Nth degree, XHTML can be represented via a giant XSLT transform with SVG as output. It would be neat if the W3C spec'ed CSS as transforms on SVG. This would take a lot of the ambiguity out of it.

Integration! Integration!

[fm6]

I agree. SVG lovers place too much emphasis on interactivity. Maybe someday SVG will challenge JavaScript, but right now that's less important than the fact that graphic support in current web browsers is screwed. Right now, most web graphics uses some kind bitmap. There's either lossless [w3.org] or lossy [jpeg.org] compression, but there's still too many bits, even if you have a fast connection. Nor do web sites like paying for the extra bandwith. SVG deals with this problem very neatly.

(No, I didn't forget PNG [libpng.org]. It has some technical and ideological advantages, but browser support is still, well, incomplete.)

So what's wrong with SVG plugins? They don't exploit the full power of SVG. It's not just a graphics format, it's an XML application. In other words, it's a markup language, just like HTML. A good XML-aware browser (something both IE and Mozilla pretend to be) shouldn't isolate SVG from the rest of the document.

Consider the gif-filled Slashdot page you're looking at right now. They have gotten rid of a lot of bitmaps (though the left hand clickbar looks slightly less cool as a result). But they still use some weird little bitmaps [slashdot.org], plus a lot of weird tables and font kludges that are hard to maintain and tend to be browser dependent.

There's a simple fix: put SVG support in the browser (it is a W3C invention after all) and allow indiscriminate embedding of XHTML and SVG in each other. (Not to mention any other XML applications the browser happens to support.) The Mozilla people know this [mozilla.org], but still consider SVG support experimental and non-standard. This has been the status quo for quite some time, and given AOL's abandonment of Gecko, is not likely to change.

Maybe if Mozilla had concentrated on basic technological improvements like this and less on eye-candy and silly features... well, AOL, would probably still have screwed them over. But I might feel bad about it.

KHTML looks to be the new leader in open-source web browsers. And their does seem to be a lot of interest in using the engine to render SVG [kde.org]. Alas, the KDE people still think of SVG as something you embed in something else.

Re:Sigh

[Gord Bowman]

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.

kevlindev

[AnEmbodiedMind]

This is similar to KevLinDev's SVG GUI [kevlindev.com] code.

While the Corel guy is using an XML GUI language, this is the Scripting approach that the he has chosen not to use. With the code on the KevLinDev site you can create various SVG widgets, with a call to a javascript function.

I think I'd prefer to do it this way, rather then use XML if I was doing it by hand, as it is closer to normal GUI API's then some verbose XML language. I guess the XML approach would probably be great for the back-end standard for various IDE's

The most interesting thing about the KevLinDev stuff is how some of these javascript calls allow you to provide what the guy calls pSVG, (parametric SVG). pSVG is really just a hack to try and address some of the deficiencies of SVG - hopefully some of these ideas get into the official SVG spec at some stage so you don't have to hack around it like this.