Article:		SVG: A Sure Bet
Subject:		Svg can not be used as an interchange format
Date:		2003-07-20 11:41:26
From:		Paul Prescod
Response to: Svg can not be used as an interchange format
Of course any interchange format is going to lose some details of the native formats. It is quite rare to find one that does not. And yet we still make heavy use of them. When you cut and paste from one application to another you usually go through RTF or ASCII text which loses things. But people still cut and paste. If you want to integrate graphics from GIS software with graphics from a charting package, SVG will preserve everything that you could reasonably expect it to preserve. As the article said: "SVG will also become the interchange syntax for all sorts of industry-specific or corporation-specific data visualization systems, from maps of oil fields to architectural designs to molecular models. It will not replace the native XML data vocabularies for these things, but it will allow them to be rendered to a single display format so that disparate types of image can be integrated into unified graphical applications delivered through web browsers." But I will defer to the experts: "SVG has emerged as the new high fidelity vector graphic standard for the Web. Dozens of applications have developed or announced their intent to support the SVG format. This made SVG a natural candidate as the Visio team evaluated alternatives for exchange of Vector graphics with other applications going forward." And: "Over many releases, the Visio team had built or acquired import and export 'filters' for a large array of foreign graphic formats. Many of these were proprietary formats of competing products. In Visio 2002 release, the number of formats supported for import, export or both had reached 27 formats, 12 of which were proprietary formats of other products --- some of which had already announced they would be supporting SVG. The Visio team decided to deprecate support for a number of older formats and to add a single new format that would be supported by a wide array of other products --- SVG." Richard See, Lead Program Manager ? Advanced Technology Teams, Microsoft Office Visio, Microsoft Corp. http://www.svgopen.org/2003/papers/SVG_Scenarios_using_Microsoft_Office_Visio_2003/#S2.2 You asked whether I see some of the same issues with SVG that I do with SOAP. I think that SVG could and should be modularized more. The Tiny and Basic profiles are a good start but just a start. Yes, I think that the SVG community has to wrestle more with issues of profiling, subsetting, customization and interoperability, but I have a lot more faith in their common understanding of their problem domain than I do for SOAP.

Previous Message

Up

Next Message

• Svg can not be used as an interchange format
  2003-07-20 14:03:56 Robin Debreuil [Reply]
  
  Hey Paul,

  
  >> Of course any interchange format is going to lose some details of the native formats.

  
  It will lose whatever the spec allows it to lose, which is often zero, but at least not an arbitrary amount like 'what is supported by a third format'.

  
  >> When you cut and paste from one application to another you usually go through RTF or ASCII text which loses things. But people still cut and paste.

  
  Cutting unicode text as ascii would result in loss that would never be acceptable. All modern OS's can handle this, and most older ones will too. If your container only supports ascii, then it will have to be converted down, but you would never store it on the clipboard as ascii alone. That is why the clipboard can store data in multiple formats, and auto convert as well. Svg is generic like ascii, not all encompassing like unicode. That is a good analogy of why it can't be used as an interchange format for anything but simple cases where you don't mind loss.

  
  That would be fine, except it is a runtime format. So your data is stored across tags, entities, css, javascript, it might have to be transformed by xslt or script before being viewable, you might have to load bitmaps externally, your data might change half way through, and now rcc etc etc. This makes simple conversions like unicode>ascii pretty much impossible, because your data isn't stored in a consistent manner. That is the big reason it makes a lousy interchange format.

  
  >> Visio, the wonders, limitations are features, etc etc

  
  The visio quote has nothing to do with interchange - they are dropping support for formats, not making them easier to use. They are adding one. So if you had an older deprecated format, you now have to convert it to one of the supported ones - svg or one of the remaining formats. Is that what you meant by "solve the interoperability problems" - have a polite way of not supporting interoperability anymore?

  
  >> You asked whether I see some of the same issues with SVG that I do with SOAP. I think that SVG could and should be modularized more. The Tiny and Basic profiles are a good start but just a start. Yes, I think that the SVG community has to wrestle more with issues of profiling, subsetting, customization and interoperability, but I have a lot more faith in their common understanding of their problem domain than I do for SOAP.

  
  Ok, fair enough. Could you define the problem domain of SVG for me though, or point me somewhere that can? Maybe I would have a clearer view of why it is structured like it is if I knew the problem it was trying to solve. Right now I have a lot of 'fish or fowl' moments when trying to incorporate it into programs, or even my workflow...

  
  Cheers,
  Robin