Forgot your password?
Programming IT Technology

dSVG - A New Kind of Programming? 184

Posted by Cliff
from the soliciting-your-thoughts dept.
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.


Gord Bowman
Lead Developer, Corel Corporation"

This discussion has been archived. No new comments can be posted.

dSVG - A New Kind of Programming?

Comments Filter:
  • Sounds great... (Score:5, Insightful)

    by Tet (2721) <slashdot@astradyne.[ ]uk ['co.' in gap]> on Saturday July 19, 2003 @02:05PM (#6479255) Homepage Journal all we need are some browsers with native SVG support. With the Mozilla SVG [] project still seemingly no closer to delivering a shippable release, and no hope whatsoever of MS releasing an SVG enabled IE, looks like we're stuck with the Adobe plugin for now. Until we get past that, I doubt SVG will enter the mainstream (more's the pity).
  • by PDHoss (141657) on Saturday July 19, 2003 @02:15PM (#6479313)
    Can someone summarize if I am going to get 20-to-life and a cellblock husband if I download the spec?

    Jeez, how many paragraphs into the legal requirements do you have to be before you realize that ain't reeeeeal conducive to getting people to beta/bug track/improve your product for free?

  • Useless (Score:1, Insightful)

    by Anonymous Coward on Saturday July 19, 2003 @02:24PM (#6479364)
    This sounds like a typical case of cowboy developper meets the garage boys (See Wiki for more details). This new scheme is closed source hence, I categorically refuse to use it for my company. This smells like a lockout. Ontop of that, it feels like only that one developper worked on designing the spec. The last person I want to see design a spec is a developper (even worst if it was ONE developer). They have no clue what the users want or would like to have. Basic marketting non-sense and probably why Corel does so bad. Third thing which I already pointed out is that this software is made by Corel. Corel never made any profit except this one time when they came out with Linux and the .CON was big (Mind you the cash was not generated by Linux but some other app). If the company does not die before this, the product will be dumped exactly like all the other products they have done in the past. There are a few already good editors around; we don't need something to wanne-be better. Dynamic data? It's called Perl!
  • Re:435098734912 (Score:1, Insightful)

    by tomstdenis (446163) < minus distro> on Saturday July 19, 2003 @02:27PM (#6479387) Homepage
    What I want to know is how do you program in XML. Its a loose markup language with no real keywords other than a few tokens >, <, ", =, digits, etc...

    It's like coding in ASCII or something....What is an ASCII program?

    That and I admitedly missed the XML boat [been busy in college] but what is the big deal? so I can write


    Then write a program to scan for tags and their values. Big fucking deal. I could have used the common .ini format



    I've seen XML enabled on numerous products and I can't really fathom why its better. It takes up more room, from recent postings it isn't vary fast to deal with and really doesn't add much to the table.

    The only real benefit is it lets the data to be entered in random order [or missing fields] and still recover. Not really a new feature of properly coded data processing applications. /rant

  • by tmoertel (38456) on Saturday July 19, 2003 @02:31PM (#6479411) Homepage Journal
    I am interested in reviewing the spec, but it's presently tied to the test-suite software, which is locked away behind a long, complicated, and scary-looking license agreement that I'm not comfortable agreeing to. Could you please provide a link to just the spec?

    Since you have already submitted the spec to the W3C SVG WG, it's already public knowledge, and there's no reason to hide it behind legalese, right? Can't you just provide a link straight to it?

    I'm sure a lot of other people are more interested in the spec than anything else. If you want them (and me) to take a look at dSVG, please make the spec available by itself.


  • by Homology (639438) on Saturday July 19, 2003 @02:49PM (#6479506)
    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.

    Since this appear to be a product by a comercial company, it sort of begs the questions : Is any patents filed relating to this, or is any existing patent involved? This includes any technology necessary to implement dSVG.

    I apologize if I appear impolite, but I'm getting cynical as I age.

  • Re:Windows only? (Score:4, Insightful)

    by Tumbleweed (3706) on Saturday July 19, 2003 @02:51PM (#6479516)
    Personally, I would not buy the product no matter what platform it runs on because of the (sad) state of SVG support in the browser market, and the foreseen SVG support in the coming years. With IE not being updated for the next 2 years, only Mozilla, Opera, & KHTML variants will be likely to have any decent SVG support anytime soon, and even that is just a possibility, and hardly a foregone conclusion. Your product may be the greatest thing for SVG that has come along (not that that would be saying much, considering), but SVG support, for all _practical_ considerations, is nearly non-existent in browsers, and as a percentage of the surfing public goes, will remain so for years to come. Your product seems like a solution waiting for a market to develop. I don't think that market is GOING to develop for another 2 years, at the soonest. We'll have to wait and see if Microsoft deigns to include usable SVG support in the Longhorn-generation of IE, or whether they cripple & abandon it like they did PNG support. If the latter is the case, then your product may never be useful enough for Corel to continue to support unless Mozilla/Opera/KHTML-based browsers actually start taking significant browser marketshare away from IE.

    Good luck on what seems like a fun project, though. Some people will certainly find this product useful, but whether it's enough of a customer base to continue development on is a big guess. Risk big, win big, though!
  • by Anonymous Coward on Saturday July 19, 2003 @02:58PM (#6479548)
    I'm not trolling, I'm serious.

    Gordon Bowman wrote:
    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.

    I'm sorry to break this here on slashdot, but if you are so alone at Corel that you don't even have any (qualified) collegues to discuss design matters with, but post them to slashdot of all places to get well thought answers - maybe especially after such legal mumbo-jumbo, you should have a serious talk with your boss?

    Slashdot isn't the place to get design help for proprietary software. Either you GPL it and you can get lots of help from the community, or you stay proprietary and you get what you pay for.

  • Re:Sounds great... (Score:4, Insightful)

    by Anonymous Coward on Saturday July 19, 2003 @03:00PM (#6479558)
    People should vote for Mozilla bug 122092: "Enable SVG support"

    Voting doesn't write code. Writing code writes code. You can vote for it all you want, but if nobody writes it it won't make a difference.

    On the other side, if you write the code for it, and give it to Mozilla, then nobody will need to vote for it.

  • by bons (119581) on Saturday July 19, 2003 @03:45PM (#6479959) Homepage Journal
    So, someone is creating an OO script/language for vector graphics...

    Now that you've approaching Flash 5, can you please explain what you're hoping to accomplish?
    Since their plug-in is commonly installed, their standards and documentation are apparently about as open and propriatory as yours, and since the number of people who can tell the difference between flash and dhtml is minimal, I'm not sure what the actual goal here is.

    According to the normal timetable, Flash 7 should be released before the year is out and that seems to be your primary competitor. Unfortunately it also offers video, sound, raster graphics, and a good lead on a decent OO scripting langage. Oh wait, that's Flash 6.

    Is there something new you're offering (other than a different set of lawyers) that we should be noticing?
  • by Animats (122034) on Saturday July 19, 2003 @03:45PM (#6479961) Homepage
    It's tough to do this well. Where do you stop? When you have an animation system? A game engine?

    I'd like to see more open-source tools to create Flash format. Flash is a really good implementation of vector graphics - the engine is small, the files are small, and the system is very powerful. It took Macromedia three rounds to get it right (remember Director?) but finally, they did it.

    Flash format is open, and there are a few non-Macromedia tools for it. But not enough. I once looked into doing a Flash tool for stock charts, so you'd get the raw data from the server and could pan, zoom, and do typical stock-chart operations like moving averages locally. It's possible.

  • by omar.sahal (687649) on Saturday July 19, 2003 @04:08PM (#6480118) Homepage Journal
    Screen shots screen shots , how'd I know i want it with out screen shots
  • Re:Windows only? (Score:3, Insightful)

    by smallpaul (65919) <> on Saturday July 19, 2003 @04:25PM (#6480248)

    Personally, I would not buy the product no matter what platform it runs on because of the (sad) state of SVG support in the browser market, and the foreseen SVG support in the coming years. With IE not being updated for the next 2 years, only Mozilla, Opera, & KHTML variants will be likely to have any decent SVG support anytime soon, and even that is just a possibility, and hardly a foregone conclusion. Your product may be the greatest thing for SVG that has come along (not that that would be saying much, considering), but SVG support, for all _practical_ considerations, is nearly non-existent in browsers, and as a percentage of the surfing public goes, will remain so for years to come

    PDF support is quite literally missing from all browsers and yet PDF is quite successful. This is not just an idle analogy. Adobe is the vendor of the leading SVG viewer and they know better than anybody how to make a plugin work. One way is to bundle the SVG plugin with the Acrobat plugin which most people need to download anyhow. Adobe has done that before and probably will again in the future. If, in the next few years, SVG is "only" as successful as PDF I will be quite happy myself. So all of the doom and gloom is certainly not warranted.

    If the latter is the case, then your product may never be useful enough for Corel to continue to support unless Mozilla/Opera/KHTML-based browsers actually start taking significant browser marketshare away from IE.

    SmartGraphics Studio is for businesses. They can deploy the SVG viewer to every desktop in their system merely by adding it to their standard install. They don't need Microsoft to bless it any more than they need Microsoft to bless PDF/Acrobat.

  • Re:Flash vs. SVG (Score:4, Insightful)

    by russcoon (34224) on Saturday July 19, 2003 @04:32PM (#6480290) Homepage

    I think you're going to find out that developers at large aren't going to enjoy "programming" in XML. It is overly-verbose for anything but data and meta-data transfer (and many will argue that it's highly inefficient at even that). Programmers and you and I know them want their if statments to look as close to pseudo-code as they can get (hence we have Python and Perl). All of that said, your toolkit still hinges ona a glue language (JS) to make SVG (a declarative style language) even become a programming language in the first place. Therefor the dependency on JS doesn't go away at all. In fact, you've only made your programming environment even more brittle (what are the odds you'll get good debugging info from a dsvg environment?) while continuing to mix data and program in a way that has some deeply negative security ramifications.

    So anway, even if Flash and SVG don't compete, dSVG turns SVG into a Flash competitor, except that it's a "complete xml solution from end to end". Frankly, I'm not sure what that buys you.

    The point of CSS is to seperate style from structure, and the point of XML is to encode meta-data that would otherwise be lost. Unless you can make a compelling argument that scripting constructs are meta-data that should be encoded, I'm going to continue to have a very hard time buying that programming as such belongs in your markup as anything other than CDATA sections. Yes, it has semantic meaning, but not semantic meaning for data! XSLT treads this line pretty narrowly, and I think it winds up on the right side of the fence in most places, but it again suffers from all of the problems anyone else that tries to make imperative constructs out of markup winds up with, and that's not a good thing.

    We doen't use column-based programming languages any more for a lot of very good reasons. Why would we ever want to return to their equivalent if it's only more verbose?

    So we can put an XML stamp on it? What does that buy us?

    Anyway, Flash and SVG+JS are competitors, Flash and SVG without scripting are not. End of story.
  • by kahei (466208) on Saturday July 19, 2003 @08:15PM (#6481392) Homepage

    In terms of constructs like 'if' and 'elst', I'm not convinced that wrapping the SVG object model in a layer of xml tags will do any more good than wrapping stuff in a layer of xml tags usually does.

    However, it's good to see a widget set being produced for SVG. If a powerful, standard widget set evolves that'll be immeasurably useful in promoting SVG and taking advantage of SVGs natural strengths.

  • Re:Flash vs. SVG (Score:2, Insightful)

    by TheViewFromTheGround (607422) on Saturday July 19, 2003 @10:48PM (#6481959) Homepage

    Gord is precisely correct. I find Flash's implementation of ECMAScript very goofy. You wind up setting up layers upon layers and frames upon frames of images, vector graphics, etc, making them all invisible, and then hiding code in lots of different places on the time line and man, it's a big mess. Of course, the Flash community loves it to death at this point because it is what they now know deeply. And, especially with the MX version, can do some very cool things when it comes to interactivity online. But it is tricky and complicated to make it dynamic, work with one's databases, it is still tricky to print, etc. I've done some Flash development, and I just keep asking myself: why can't I just write straight code?

    What's important to note is that visualization of data isn't just dynamically generated graphs and reports for the corporate newsletter. Another promise of end-to-end, data-driven graphics is in creative and interesting mapping of web site relations, big statistical datasets, etc.

    Currently, I'm exploring the possibility of using SVG sometime this fall or early next year to visualize connections between news stories: how are the people in Story A related to the people in Story B and how are the themes of Story C related to the themes of Story D and how can it be visualized in a way that the connections between a large number of documents pops out immediately. For the moment, we're just looking at doing it on the site that I develop, but there are possibilities for doing it more generally -- i.e. comparing the NYT's coverage of Iraq with the Washington Post's.

    The point is, you can do this in Flash, but the level of complication makes it far from the ideal way to accomplish the task. Further, you can't very well GPL the resultant application, which is precisely what a concerned citizen might want to do with a tool that aids in the scrutiny of media or in seeing large scale statistical trends in the Chicago Police Department that could uncover corruption and deceit, just to give some really innocent examples that occur to me as I write it.

    Honestly, though, the possibilities are so significant that even without built-in browser support SVG is a pretty big thing.

  • by Cycnus (162186) * on Sunday July 20, 2003 @01:54AM (#6482655) Homepage

    I for one love the idea of being able to develop SVG applications.

    While it's true that SVG currently need a plug-in, that its installation base is quite small compared to Flash (but most people installing Adobe Acrobat install the SVG plug-in without even noticing), the SVG specification is a W3 Standard, and it's easier to integrate with other Open Source tools on the server side.

    I doubt that dSVG will initially appeal to a large public who won't see the point of it over Flash for multimedia applications, but it certain should appeal to people writing applications for the enterprise where it's easier to control what is installed on the users' machines.

    dSVG could be a great cross-platform tool (while the GUI software that build applications runs only under Windows for now, SVG runs on any platform) and could actually be helpful in pushing companies to use SVG as a standard for web applications rather than rely on proprietary formats that are not easy to integrate with Open Source development tools or that will always be a couple of step behind the commercial implementations.

    It must also be recognised that while the technology to build really powerful web application is there in IE, Mozilla, Opera and al, there are very few really interactive applications using those technologies, simply because there is not enough compatibility between the various standard implementations, and to work around those is too costly and difficult to manage well.
    We end up with web sites that use only the lowest common denominator set of technology, with is not enough to build really powerful applicative environments. So in the end, all those powerful technologies are great showcases, but get barely used in the real world.

    While Flash is not going away any time soon (it is likely that it will always remain big in multimedia environments), SVG has more potential for building rich, natural, intuitive and powerful GUIs that easily integrate with existing and well established server technologies, Open Source or not.

    I always liked Corel and their tools. I've been a fan of CorelDraw since version 2, and I really like that they are the first one who understand the role that SVG will play in application building.
    Adobe is surely the major pusher of the technology, but they haven't yet caught up on that idea that SVG can go way beyond chart applications and pretty graphics.

    What was missing was a GUI toolkit, and dSVG is looking good to fill that role, so instead of whining that the tools don't yet work on Linux or that the ULEA is 3km long, let's focus a bit on the question at hand: have a look at the specification and help if we can.
    I know I will try because I need these tools, and I think our community is about supporting and encouraging that kind of attitude from commercial companies.

  • by lyser_babich (601635) on Monday July 21, 2003 @12:20PM (#6491148)
    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. CFML (Cold Fusion) has been around since '96 (IIRC). It is a tag-based procedural language. It suffered from its accessibility to non-programmers. I'm not a fan of obfuscation for obfuscation's sake, but CFMLs reputation was hurt by poorly implemented programs designed by amatuers. dSVG could suffer the same fate, but I don't really know. I'm not an astrologer. -LB

It is the quality rather than the quantity that matters. - Lucius Annaeus Seneca (4 B.C. - A.D. 65)