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"
...now 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).
"The invisible and the non-existent look very much alike." -- Delos B. McKown
...screenshots link?
MOD THIS ONE UP +5 FUNNY
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...
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?
Sounds unique, thus quite interesting.
Are there any existing examples, any customers who have implemented production-quality web apps in this way?
Cool stuff.
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?
PDHoss
======================================
Writers get in shape by pumping irony.
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.
Is it just me, or is this just reinventing the wheel? It sounds like reinventing Flash only worse (because you have to "program" in XML).
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.
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!
- -
Are you an SF Fan? Are you a Tru-Fan?
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!
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?
Cantankerous old coot since 1957.
http://www.corel.com/smartgraphics/resources/dSVG1 1
:P
WoW one of the longest disclamers I have read in my life
I am trying to *complete* my SVG/XML/CSS editor for 2 years... and now they want to add new features!!!
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!
Easy, automatic testing for Perl.
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.
"Hi, my company just came out with a new product and told me that I get a huge stinkin bonus if I managed to get an advertis^H^H^H^H^H^H^H^Harticle on it posted on /., so please click on this link..."
I didn't have any luck with the Corel :-(
SVG Viewer and Mozilla 1.4 on W2K.
I suppose a Linux version is totally
out of the question...
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.
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.
Goto Adobe's svg demo site with corel's plugin and it tells you you need adobe's. Goto Corel's svg demo site with Adobe installed and it tells you that you need Corel's.
Well.. maybe. Or Maybe not. But Definitely not sort of.
"SVG is still a standard? :o I thought that it lost the battle, war, and it's ability to procreate to SWF... Has anyone actually come across anything that is SVG based? In fact, I wonder how many people here actually knew what SVG was before reading this article..."
Before you get on your Macromedia Flash bandwagon. You might want to look at who was part of the working group.
Can anyone tell me? I've used svg + javascript + DOM. IT works very well and is supported in adobe's pluggin and is the offical w3c recomendation for making svg dynamic. Why confuse the situation? What need is there for dSVG?
Well.. maybe. Or Maybe not. But Definitely not sort of.
-1, screenshots are too small, resubmit
oh, wait, this isnt K5...
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
Still, I think SVG is likely to be a sufficiently valuable addition to browsers that it is worth pushing for.
I know it's not open-source, but we HAVE proposed the spec to the SVG Working Group for consideration. I want it to LEAD to a standard, after lots of feedback and collaborative discussion, not to BE the standard as-is. I'm only one developer--what are the odds that I thought of everything? Zilch.
"It was a programmer's dream. I was essentially being paid to develop a new kind of programming language."
How often has one programmer's dream become the nightmare of many others? Especially when associated with the claim "you don't need programming skill" to use the language.
We already have Basic!
Sorry about being so negative. But I've had way too many bad experiences with claims "no skill necessary" if you use my product.
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
By that criteria, PPOP (Power-point oriented programming) will be the wave of the future.
Table-ized A.I.
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.
It seems references to this have one foot in GUI's and one foot in graphics rendering. I think it is best to separate them because one is primitives and the other higher-level form widgets that fit GUI behavior expectations. Candidate remote GUI XML standards include XUL, XWT, and SCGUI (my pet), among others.
Table-ized A.I.
How is dSVG any different from SVG + ECMAScript?
Can it can create content as rich as flash, like see http://homestarrunner.com?
r4lv3k
LEt's fuck
OK. Bend over.
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?
No Zen is good zen
...another TLA to throw up (yes, this was properly choosen) onto the the ol' career outline formally known as a resume and now known as the input for a buzz-word filter.
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.
.. 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.
Screen shots screen shots , how'd I know i want it with out screen shots
you may be aware that SVG is increasingly being used for the creation of data-driven Web applications.
Yeah right...like has anyone ever really created a data-driven web application with svg? Please!!
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
Even though current flash usage sucks, it's actually a pretty nice vector graphics platform, and it's the best out there for what it does. The flash file format specification is available for free download from macromedia, but they no longer make their sdk available.
:-p
I'd like to see a decent library (c and c++)based on the specification created.
And, come to think of it, I'd like to see a decent library based on the full MPEG4 specification created as well.
Now go to it!
I'll be checking the replies to this post within the hour, and the above assignments better be completed by then.
Every so often I look at these things closely to see what amusements lie therein. This one has some fun bits. Some of these seem to stem from an attempt to build a license for every possible product and combination of products - thus in this single license you're agreeing to licenses for Clip Art, iGrafx (or IGRAFX - possibly a different product, who knows), Trellix, some SDK and in every country possible. So, here are a couple excerpts from the license that I found amusing....
YOU MAY: (i) install and use one (1) copy of the Product on a Computer up to the Permitted Number of Computers. You may also make and use a second copy of the Product on a home or portable computer provided that copy is never loaded in the RAM of the home or portable computer at the same time it is loaded in the RAM of the primary computer;
What if the OS keeps things loaded till the memory is claimed by another process?
And the "a Computer up to the Permitted Number of Computers" makes me believe that lawyers are indeed talking a different language entirely. (Leaving aside the Capitalization, of course.)
There is a whole paragraph on GIF licensing from Unisys. Did that patent expire or not?
In reference to clip-art images : ...
not be made available for downloading separately or in a format designed or intended for permanent storage or re-use by others;
The image shall
Like jpeg?
You may only download, install and/or Use the Product if: (i) you are not a citizen, national or resident of, and are not under the control of, the government of: Cuba, Iran, Iraq, Libya, North Korea, Sudan, Syria, Serbia, Taliban-controlled areas of Afghanistan,
Does that mean that there are Taliban-controlled areas of Afghanistan? I thought the shrubbery and the rummy had forbidden that.
And isn't the government of Iran now the group that the US put in place?
If you are a business in Germany or Austria, the courts of the Province of Ontario, Canada shall have exclusive jurisdiction over any matter arising hereunder.
Not the courts of Germany or Austria? Interesting idea that. And who has jurisdiction if you live in (say) Belgium?
You agree that this Agreement and all documents contemplated hereby be drawn up in English. Vous consentez à ce que cette entente et tous autres documents envisagés par les présentes soient rédigés en anglais.
You must admit that saying that all the documents be drawn up in English and then saying the same thing in French is just a bit self-contradictory.
But I also quite like the "All documents contemplated hereby". Does that include this slashdot posting?
Several paragraphs are in ALL CAPS. Does the case of a character imbue in it Special Significance?
One more tool for the trade.
Let's go for beer.
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;
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.
Dunno why that semicolon is appearing before the button element...
G 11" xmlns:xlink="http://www.w3.org/1999/xlink" height="410px" width="744px" onload="init(evt)" viewBox="0 0 744 410">
t on" autoScale="true" disabled="false" selected="false" toggle="false" height="18" width="100" y="100" x="50" label="setTransform" id="dsvgUniqueID_0">
<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/setTransform.js"/>
<dsvg:button xlink:href="dsvg11/skinButton_Windows.svg#skinBut
<dsvg:setTransform cy="175" cx="300" rotate="30" vAlign="middle" hAlign="middle" absolute="false" elementID="shape1" id="dsvgUniqueID_1"/>
</dsvg:button>
<rect height="50" width="100" y="150" x="250" stroke-width="5" stroke="darkblue" fill="#5f86B1" id="shape1"/>
</svg>
(No, I didn't forget PNG. 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, 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, 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. Alas, the KDE people still think of SVG as something you embed in something else.
It can be scripted and can contain scripts and fire events, it forms part of the page's object model, it's *not* like implementing 'just another image format'.
Yeesh.
Whence? Hence. Whither? Thither.
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.
Whence? Hence. Whither? Thither.
I don't think this simplifies UI coding enough for people to consider switching. I may be confounded by the verbosity of the spec though.
For example: is it really necessary to specify the skin on every element? All those XLINKs should default to sensible values unless I want the controls all to be purple for some reason, in which case I can understand the need to be verbose.
CSS is a great tool for tweaking the look of something. Could you not leverage that? stateHover and the like are re-inventing stuff that CSS already does.
I like the way list and menu elements are defined, although it may be overkill for most uses (having just an ID for each element should be enough).
My gut feeling is that this is not simple enough. The heuristic is that a new tech has to offer roughly a magnitude in improvement for it to take off. I don't see this as being 10x easier than javascript. Maybe my eyes are clouded. Try asking a novice what he thinks.
Who is going to use this? People who develop complex apps are going to deal with programming anyway, so they won't use this over XForms or HTML forms or Java applets. People who are throwing together web sites will use HTML forms and canned scripts in Frontpage or DreamWeaver.
I'm not sure this a middle ground between HTML forms and DHTML that's worth taking.
ì did not read this spec, but i hope it's as simple and straightforward as svg. I produced some impresive results with SVG within 4 hours.. usallly it takes much longer to get the hang of a standard/format/language.
Neat! For Gord's next trick. He's going to do a SVG picture of the Goatse.cx man.
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.
Why bother? That arsehole who is CEO of Corel is going to sell the whole kit and kaboodle for about 1/100th its actual value to some private outfit in California, who is going to kill the company because Microsoft wants them gone.
It is a complete piss-off. Corel is just about to hit turn-around point now, has an infuckingcredible product lineup -- Painter, XMetal, Ventura, iGrafx stuff, Graphigo, Draw -- and looks like its ready to really start kicking ass.
But no. Kill it instead. Even Cowpland could not accomplish what Burney is proposing.
--
Don't like it? Respond with words, not karma.
Do *any* of the browsers have SVG rendering support by default? Mozilla, IE, and Firebird don't. The adobe plug-in is free, but it'd be nice if it was ready from the get-go.
The *idea* of SVG is great, but I don't want to invest alot of time learning a spec for something that no one will use.
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.
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.
First off, let me say that I have toyed around with the Corel SmartGraphics Studio, and I think that it's a very good first pass at simplifying the process of creating SVG for a lot of users. As a big fan of SVG, I appreciate all the effort that Corel has put forth.
That being said, I think that the Open Source community should know that dSVG is only one of three UI-defining proposals that the SVG Working Group is considering for SVG 1.2. One of the other two, currently known as RCC, proposes the ability to create a kind of template with a separation of style and functionality, but defined in the document rather than being built in the plug-in. Ultimately, I think that this is a better way to go, since it is far more adaptable. It uses scripting and an XSLT-like syntax to transform semantic content into graphical elements (like form controls, scrollbars, etc.). The last proposal, Live Templates, seems like a generalized case of RCC, and I suspect they could be married together.
Adobe has released a tech preview of ASV6, the next version of their plugin (Windows only for now). It implements an early version of RCC (as well as some other cool features like text wrapping, audio, video, and external resources), and looks very promising. At SVG-Open, I saw an RCC forms widget toolkit for SVG, which worked well and weighed in at all of 6KB. I also saw ASV6pr working on a Linux box, and with the latest build of Mozilla. It's still buggy, but it's more conformant to the Spec than ever.
May the best spec proposal win!
In other news, the excellent Batik (an OSS SVG toolkit) also released a stable 1.5 last week.
Basically, SVG is getting really exciting.
...that could be of interest to everyone else too.
While its a good thing that the specification for dSVG be proposed as a candidate for a standard, it currently clearly isn't one and the only existing implementation relies on DTD and EcmaScripts that have been developed by Corel and are own and copyrighted by Corel.
It would be many moons before dSVG ever becomes a standard, if ever (I hope it will be though).
In the meantime, anyone wanting to use dSVG would either have to use Corel's scripts or rewrite the whole language implementation.
The latter clearly being a potential trouble for a burgeoning new language (everyone could have her own variation, especially as dSVG is far from being complete and stable in features), if Corel is serious about getting people to use dSVG (which I think they are), then they should release their implementation under an Open Source license.
It doesn't have to be the GLP which is too strict and may probably slow the adoption of dSVG in corporate environments, but something like the Artistic License would certainly ensure that people are free to use Corel's fine work without fear of getting in trouble.
Another question regarding the performance of dSVG: since it is yet another abstraction layer over what is already a fairly thick pile of interpreters, parsers and renderers, it's not fast.
By that I mean that long lists and complex interfaces take quite a bit of time to update. This makes me wonder about building complex applications, or even simple ones that display a lot of data in lists for instance
Do Corel have any plan to incorporate dSVG directly inside their plug-in?
That would certainly save time (there are a lot of ecmascript files to be loaded and interpreted), and should make the interface more responsive.
Plus it would give Corel's plug-in and edge over the Adobe's, in the corporate world at least.
I think the choices that Corel do now are going to affect the adoption of dSVG very significantly, and I'm not talking about just commenting on the Specification itself, as good and promising a start as it may be.
CycnusCheck 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.
Another issue I have with PNG is that some software seems to generate illegal images. I volunteer at Distributed Proofreaders and every once in a while Mozilla chokes on a page image that's an illegal PNG file. The really irritating thing is that Mozilla is actually able to read the image itself, but if it's allowed to download the very end of the file it says, "This is an illegal PNG! I can't let you look at it anymore!" I have to download the page image and read it with a less intolerant image browser. A pain.
As if that weren't enough, IIS doesn't ship with a metadata entry for PNG. Which, predicably enough, doesn't matter to IE, but screws up more compliant browsers.
Of course, none of the problems are the fault of the PNG people, who have created some very sexy technology. But until PNG images can be displayed reliably, it makes no sense to insist that everybody should migrate away from GIFs.
There's also the little detail that the notorious LZW patent has expired. That removes one of the big motivations for creating the PNG standard in the first place. Yeah, GIFs don't have as many cool features, but they're still adequate for most people's needs.
Could be that svg might reap benefits that could really be great for music notation given the right approach. The Recordare musicxml extentions could be used to quickly format music notation through a browser interface using rapid update through svg. Given that then the browser functions could be used along with other parts of the existing interface to speed up the notation gui the possibilities are intriguing. Not that it would replace true music notation software but it could become a very quick way for teachers to send music examples, composers send simple ideas to musicians , and more importantly generaly give those who are musically literate a chance to communicate on the net. There have been several java based designed for this purpose (one out ot the University of Toronto) called JscoreMl. It was not very good because the xml tech at the time was not very advanced. There is no reason why in future advanced xml interfaces won't be able to notate, and send music, right within a browser.
OH THE SHAME I fell off the wagon and use sigs again!
the creation of a 3d-object, or shopping mall is on many developers minds. i'm wondering if there is a bench mark for this type of requirement?
Bingo. This, IMHO, is what SVG desperately needs. A good IDE to develop SVG apps. Adobe and Corel provide SVG export for static images, but there's nothing like Dreamweaver or MX Studio for SVG - from a big vendor. (There is XStudio. But they're a small vendor in Europe. Maybe one of the bigger boys will buy them up?)
If Corel came out with a nice IDE using dSVG, nobody would care whether it was a standard or not. They'd just use the IDE to create cool interactive content.
- Jasen.