Question about Stylable SVG

From the spec:
  Because Stylable SVG requires the use of a styling 
  language before rendering properties can be attached

  to graphics elements, and because Stylable SVG 
  allows arbitrary styling languages to be used, 
  Stylable SVG is not suitable as a self-defined, 
  fully-contained language format for guaranteed 
  interoperability.

The question is, who has the expertise to build a
good SVG viewer now?

Microsoft and Netscape have good web browsers, so 
hopefully they will have the technology to process the
latest "arbitrary styling language." But neither of 
those companies are known for leadership in graphics 
technology.

Adobe, Macromedia and Corel are leaders in graphics 
technology. But these companies don't makes web 
browsers, so they are unlikely to have technology that
normally belongs in web browsers, such as ability to 
parse the latest "arbitrary styling languages."

The complexity of SVG has gone up quite a bit with
this latest version of the spec. It is now not
possible
to implement a viewer with a reasonable amount of
effort. The CSIRO and IBM viewers will probably be
left in the dust.

If you do not agree with the above, then that
automatically means Exchange SVG serves no purpose!!!

Exchange SVG will probably die a natural death
any way. Here's why: Most SVG pictures on the web will
be Stylable SVG. Customers will evaluate tools based
on whether they are able to open Stylable SVG or not.
If you are a tool maker then you'd better be able to
open Stylable SVG. Or your competitor who can will
put you out of business.

Two types of SVG files will cause consumers a lot of
confusion. If a product says it can open SVG files,
customers will not know exactly what that means. Some
products that advertise the ability to open SVG files
may not really be able to open the customer's SVG
file, which will lead to frustration to the customer,
which will in turn lead to reduced acceptance for SVG.

It certainly is nice that SVG works well with, and
leverages other web standards. But although this is
nice, this is not practical.

My suggestion is to have only one SVG. This SVG should
not be overly complex. The number of languages a SVG
Viewer is required to implement should be limited --
preferably only one! Thus the effort required to 
implement a SVG Viewer will be finite, and SVG will 
work well as an interchange format as well. Companies
that have expertise in graphics, but no expertise in 
web technologies will be able to leverage SVG too.

Two SVGs is a terrible idea.

Thanks for listening, and I hope I have been able to
articulate what many others are no doubt thinking.


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Received on Wednesday, 8 March 2000 00:46:10 UTC