Article:		An SVG Case Study: Integrated, Dynamic Avalanche Forecasting
Subject:		Non-proprietory SVG is even better!
Date:		2003-04-24 12:09:38
From:		Robert McKinnon
Because the Avalanche Meteorology Toolkit (AMT) does not strictly adhere to the SVG 1.1 specification[1] I am unable to use it with the Squiggle SVG Browser. Strictly adhering to Web standards[2] reduces the cost and complexity of development while increasing the accessibility and long-term viability of any site published on the Web. I am a Linux user who views SVG content using the Squiggle SVG Browser that comes with Apache's Batik SVG toolkit.[3] I have found two reasons why AMT does not work on Squiggle: 1) AMT's SVG does not match the SVG 1.1 specification in a few instances. For example, 'left' and 'center' are not valid values for the text-anchor property. The valid values from the specification are 'start' and 'middle'.[4] 2) AMT makes use of proprietory Adobe SVG Viewer features that are not part of the SVG 1.1 specification. Rather than using Adobe's server-connection capabilities to load external data sources, xlink:href links in the menu could be applied to achieve the same effect. A click on the menu would then request new pages from the server, thus making use of the traditional HTTP GET request to retrieve new data views. As it stands the AMT looks like a great toolkit, however currently it's a proprietory Adobe SVG Viewer application. With a little work it could be made into an awesome open-standard, cross-platform compatible Web application, by strictly adhering to existing W3C Web standards. [1] http://www.w3.org/TR/SVG11/ [2] http://www.webstandards.org/about/ [3] http://xml.apache.org/batik/ [4] http://www.w3.org/TR/SVG11/text.html#TextAnchorProperty

Previous Message

Next Message

• Non-proprietory SVG is even better!
  2003-04-25 14:53:37 Tyler Cruickshank
  
  Robert,

  
  Thanks very much for giving our article a read and for providing some good food for thought.

  
  In short, we agree with your comments. SVG is open-source so we ought to stay away from any proprietary features.
  On the other hand, when we originally built the toolkit a year and a half ago, we simply wanted to get it done. Most of our users prefer the easiest method of viewing the SVG, therefore, the Adobe viewer was the easiest solution. Having said that, now that we have the toolkit functioning and are more familiar with dynamic data-driven SVG we should and intend to go back and remove the proprietary features.

  
  Down the road, if we keep our SVG adhering to the W3C standards, we wont have to worry what viewer is being used.

  
  Thanks for reminding us.

  
  -tyler