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"
Future possibilities for improvements (Score:5, Informative)
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.
Re:Sounds great...Less filling. (Score:1, Informative)
Re:Examples, Applications ? (Score:5, Informative)
Re:Goodbye RFC, hello Slashdot (Score:5, Informative)
Well, from download [corel.com] 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.
Re:Goodbye RFC, hello Slashdot (Score:4, Informative)
Code examples (Score:2, Informative)
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
Re:Windows only? (Score:2, Informative)
Re:435098734912 (Score:2, Informative)
The big deal isn't so much XML as the tools to manipulate XML data such as XSLT, XPath, DOM, and SAX.
Re:Can you please post the spec by itself? (Score:5, Informative)
Direct link to the spec (Score:1, Informative)
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.
The funny thing is... (Score:1, Informative)
Just my 2
Example Markup - checkBox and setData (Score:3, Informative)
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;
Re:Waiting for SVG pop-up windows. (Score:5, Informative)
Let me see:
Re:Waiting for SVG pop-up windows. (Score:2, Informative)
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.
Re:Any new actual features? (Score:2, Informative)
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.
Adobe SVG viewer (Score:2, Informative)
Of course MSDN Magazine [microsoft.com] covered SVGs last month. Of course I'm biased given that I wrote that article.
Cross-browser interactive applications (Score:3, Informative)
Check out TIBET [technicalpursuit.com] 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.