dSVG - A New Kind of Programming? 184
"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"
Sounds great... (Score:5, Insightful)
Holy legaleze Batman! (Score:5, Insightful)
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?
PDHoss
Useless (Score:1, Insightful)
Re:435098734912 (Score:1, Insightful)
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
<sucks_level>5</sucks_level>
Then write a program to scan for tags and their values. Big fucking deal. I could have used the common
[stuff_tom_knows]
sucks_level=5
etc...
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.
Tom
Can you please post the spec by itself? (Score:4, Insightful)
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.
Thanks!
Any patents involved? (Score:4, Insightful)
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)
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!
Re:Holy legaleze Batman! (Score:2, Insightful)
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)
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.
Waiting for SVG pop-up windows. (Score:3, Insightful)
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?
Where does it stop? (Score:3, Insightful)
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.
I need screen shots (Score:2, Insightful)
Re:Windows only? (Score:3, Insightful)
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)
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.
How is this better than regular SVG scripting? (Score:3, Insightful)
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)
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.
Best thing that happened to SVG in a while (Score:2, Insightful)
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.
Re:Goodbye RFC, hello Slashdot (Score:2, Insightful)