Article:		SVG: A Sure Bet
Subject:		State the current situation not just the possible future...
Date:		2003-07-17 06:40:03
From:		ethan estes
I have a real problem with your views on reality of the ease of use of xml. First off I deal with a ton of IsoDraw files and have worked with web cgm. My experience with SVG is very similar-"Get back to me when it does more than create zoomable maps." The technology is slow in the browser-Adobe's reader specifically. BTW: YOU STILL NEED TO DOWNLOAD A COMPANY's PLUG-IN TO VIEW SVG. You still need a graphics app of some sort to make them like illustrator (for anything complex and useful.) Corel has some software out but it is similar to isoDraw in that you have to buy their server etc. They are not cheap either. You need these apps to build things like Wiring diagrams-the real ones not the simplified versions floating around the web that are so easy to make. Your markets are fragmented-multiple versions for different markets ie SVG Tiny. This technology is really only good for an audience who excepts all it's limitations and playback performance issues because the see the promise of it. It does have promise but you need to be a little more honest on it's current state to the people in the trenches working with this stuff. I watch the format all the time and not once has it been a viable format to move intelligent graphic data around in our workflows. And again you have a long way to go to get to the usability of flash files.

Previous Message

Next Message

• State the current situation not just the possible future...
  2003-07-21 11:46:57 Rob Williamson [Reply]
  
  Two points to add to this long string....

  
  Point 1: Clarifying an Small Misconception

  
  I just need to clarify something regarding building SVG applications using the Corel Smart Graphics Studio. You do not, in fact, need a Corel Server to deploy a data driven SVG application. We have a component called, "Process Builder" that allows developers to visually build run-time connections with data and logic without having to write ASP or JSP code (or actionscript for that matter). If you want to build these processes quickly and deploy them on a server that includes some added functions (like image serving, or CGM-SVG conversion) then you need a server.

  
  However, the output of the product is open standard XSLT, SVG, and ECMA that you are free to deploy on the application server of your choice to the viewer of your choice. Our environment does not use any custom extenstions not usable by other viewers or authoring tools.

  
  Again, this speaks to the value of SVG and the underlaying technologies....choice! As long as you are careful to not use proprietary extenstions then you are able to view it and use it in any tool in the 'content' delivery workflow.

  
  Point 2: An observation on this thread

  
  The real opportunity that Corel is seeing is not in making SVG as the be all and end all of XML and W3C browser technology that will replace the desktop as we know it. While this would be fantastic, if the entire SVG community budgets were all added up probably wouldn't be 1/10th of the R&D budget of Microsoft so extending the technology in this direction seems a little aggressive in this early phase of the technology. Exciting, to be sure....but aggressive.

  
  However, what SVG is today is a powerful and low cost enterprise tool for accessing XML data being exposed through Web Services (or ODBC, or HTTP, etc). All enterprises want is:
  1) an assurance that it solves their needs - which are rarely all that complex
  2) that it will interoperate with other vendors seamlessly - without proprietary extenstions or compiled code

  
  That's it....very simple. That is why I am so pleased with the potential of the vendors in this community and the sense of sharing that came out of the SVG open. Now we just need to make sure we don't fall prematurely into any pitfalls resulting in 'proprietarizing' SVG during *any* step in the content flow, from server side databases to client-side interfaces.
  
  
  

• State the current situation not just the possible future...
  2003-07-17 18:11:03 Paul Prescod [Reply]
  
  Ethan says: "Get back to me when it does more than create zoomable maps"

  
  SVG already does animation, video, rendering of arbitrary XML, restyling and is fully scriptable and programmable. It is not even close to CGM.

  
  Ethan says: "YOU STILL NEED TO DOWNLOAD A COMPANY's PLUG-IN TO VIEW SVG."

  
  This is true, for now, if you do not already have the SVG viewer (which you will probably get as a side effect of downloading Acrobat once ASV6 ships). But SVG is being directly implemented in at least one browser: Mozilla. I can't predict if or when Microsoft will follow suit but we know that their Visio group is interested in SVG.

  
  Ethan says: "It does have promise but you need to be a little more honest on it's current state to the people in the trenches working with this stuff."

  
  The amazing thing about the response to the article is that I really meant to be clear that SVG is not ready to take on Flash yet: " It is already clear that SVG will own those markets long before it gets close to replacing Flash and PDF in their core markets"..."Note again how SVG can win without fighting Flash or PDF."