Slashdot Mirror
dSVG - A New Kind of Programming?
"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"
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.
This sadly is unfortunately true. I have to do some of my SVG development using IE, and the Adobe SVG plugin (which hasn't been updated BTW). X-Smiles isn't really a browser in the sense Mozilla and IE is. All the rest is either outdated, or beta/alpha. Amaya with OpenGL has issues with my libraries. This overall is a sad state of affairs for something that's suppose to be a standard.
You can find some demo apps at www.corel.com/smartgraphics/resources. As for apps created by customers, I don't know.
Well, from download page we have :
This file contains the proposal submitted to the World Wide Web Consortium (W3C) SVG Working Group to enhance SVG's support of enterprise application development for dynamic interfaces
along with an EULA whose length put even the MS one to shame.
However, I can't download the proposal without first agreeing to the EULA, so good riddance. If I was sufficiently interested I probably could look it up at W3C site.
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.
IDE's to make programming a language easier is always a good thing. Vector graphics client is still dominated by Flash, but demand for more widespread SVG clients will occur when there are apps for it.
HTML pasted from the Spec, judge for yourself how it looks:
9.6 Example #1
dSVG sample behavior: focus - with added attributes focusGroup and focus
Content of file: dsvg:focus, dsvg:setTransform, dsvg:setAttribute, dsvg:setStyle, (added attributes dsvg:focus, dsvg:focusGroup)
The dsvg:focusGroup attribute adds the ability to store the ID of similar type elements that are assigned to that group.
Default focus can be given to an element (red circle above) by adding the dsvg:focus attribute to that element.
The red, blue, green circles are part of the focusGroup. The orange circle is not.
Click on the red, green and blue circles to set focus.
Hover over the 'red', 'green' and 'blue' text elements to set focus.
red
blue
green
orange
Hovering the mouse over the 'text' element with id="blueText causes the behaviors within the second 'focus' element to be run. When the first 'setStyle' behavior is run, its 'value' attribute, which is equal to:
%(textGroup@elementID)@cdata%
resolves to:
%blueText@cdata%
which then further resolves to:
blue
9.7 Example #2
Pushing the button will run the 'alert' behavior. Its 'message' attribute, which is equal to:
message= "%button1@label+ ' button ' + if(button1@selected == 'false' , 'is selected', 'is not selected')
which resolves to:
"button1@label + ' button ' + if( false , 'is selected', 'is not selected')
which further resolves to:
Evaluate button is selected
VIVA1023.com | Political Fashion.
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!
XML is simple and can be extended to fit almost any hierarchical data. An imediate benefit over ini format is that tags can be nested. There are also attributes of the tags. The reason XML is a big deal is it is a standard for marking up data that everyone can be happy with. The tags (both start and end) make it good for streaming as programs will know when the end of a block of data is. With xml schema or DTD's a specific language can be specified and an xml file can be verified to match that language easily.
The big deal isn't so much XML as the tools to manipulate XML data such as XSLT, XPath, DOM, and SAX.
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.
dSVG11Spec.zip
Jeeze Corel, don't be wankers. If you want a *public* review of your specification for a _proposed_standard_, don't make people agree to give away their first-born.
I spent a few hours yesterday redesigning my website to incorporate SVG as a design element. I was pleasantly suprised about how easy it was to get everything working properly and completely W3 compliant. What's more is: all the site resources and the template I'm using boil down to just under 6KB. I'm running all this through Mason, so I'm pretty excited to see what can be done through combining Mason and SVG. I'm thinking database-driven graphs, user layout/color/theme preferences... I know that Flash and SVG aren't direct competitors and each has it's strengths and weaknesses, but SVG's main strength (IMHO) is it's coplete openness and roots in XML. This allows SVG to be as dynamic as you want. The only things I see that Flash has over SVG are: XML sockets, more widely accepted, and it's a somewhat difficult format to reverse engineer / yoink code from. I suppose the last "feature" is both good and bad.
Just my 2
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;
Let me see:
- The ability to navigate using the traditional
back/forward buttons (although I believe the lastest
versions of Flash support this to some extent).
- The ability to resize text so it's halfway
readable.
- The ability to cut and paste text.
- The ability to use my standard ctrl-pageup/pagedown keys to switch between tabs
in Mozilla (as well as other browser keyboard
accelerators) without them getting intercepted
by the Flash plugin.
- The ability for search engines to index the
content I'm presenting.
There are many reasons why Flash is fundamentally flawed, and SVG is a much better solution in the long run. Only time will tell if the market is able to see that."The invisible and the non-existent look very much alike." -- Delos B. McKown
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.
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.
The Adobe SVG viewer recently, and surprizingly, had a beta of version 6.0 come out. This can be found here. Of course because the Mozilla folks changed the plug-in mechanisms, it still crashes Mozilla, but this is great news from Adobe as many rumors were that the entire SVG team was canned. Obviously that isn't true, and they continue to develop upon it. Corel, as you obviously know if you read even the summary of this article, has a great viewer out as well, along with a variety of tools for working with SVG.
Of course MSDN Magazine covered SVGs last month. Of course I'm biased given that I wrote that article.
Check out TIBET from Technical Pursuit. It's a full browser application environment, built using JavaScript. They decided on JavaScript, because it's the only language guaranteed to be on the client side. When they were building out the libraries, they found that it was more powerful than they expected. They've actually extended the language, using only the language itself.
Applications have to pull down a large (1 MB plus) set of JavaScript libraries. So this isn't for web applets, or even server-based web applications. (Although it's easy for the code to communicate with the server.) It's meant for full-blown applications that will run completely in the browser.
They also include some application development tools. (I haven't taken a look at those yet.) The whole thing is available under an Open Source license or under a proprietary license if you prefer.
Software sucks. Open Source sucks less.