Re: Question about Stylable SVG

chris boothroyd wrote:
> 
> I think Apu is absolutely right.  SVG was really starting to come
> together, until now.  The specs were looking good and alot of people
> were putting alot of time and $$$ into supporting it, writing viewers,
> product planning etc.  Sure it has a few short comings in font/text
> handling but wow what a great first stab at something the net could
> really use right now. 

Thanks.

> As an implementer my two cents worth is this -
> Don't try to make this everything to everyone right now.  We don't all
> have the deep pockets and teams of engineers to implement SVG now,
> unless that is the intention of certain members on the SVG commitee.

So you see this latest spec as significantly increasing complexity compared
to the previous ones?
> 
> Start with something a little simpler, give it a chance.

Its always a tradeoff - make it too simple and it doesn't have enough
power, or people are stuck with "version one didn't support that, we can't
use it". Make it too complex and, as you say, implementors get scared off
(although authors and users still get attracted, assuming it doesn't scare
off *all* developers.

> Apu Nahasapeemapetilon wrote:
> 
> > >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."

So it depends on what they can pick up and integrate. Or even (gasp) work
together ... yes, the graphics companies don't have long-term experience
with parsers (though some would say the browser companies don't have that
either ....) but they can pick up things like XML parsers, XML DOM, CSS
parsers, etc which make it easier.

It remains to be seen who has the easier job, but I am reminded that I once
said it is easier to write or bolt a network stack onto a wordprocessor
than it is to write or bolt a complete flow model multilingual text
renderer onto a network tool.

> > 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.

Well I guess we will see. I note that there are some new implementations,
such as Jackaroo, that look very promising.

> > 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.

Perhaps. We are certainly getting feedback that having two
non-interoperable languages was a bad idea (which we knew, but were as you
say trying to please all of the people).

> > Here's why: Most SVG pictures on the web will
> > be Stylable SVG. 

Certainly that is the case so far.

> > 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.

So far, most of the tools (well, all but one) use Styleable SVG with CSS. I
have seen one that uses stylable SVG with XSL, and of course XSL extensions
to provide graphical FOs.

> >
> > Two types of SVG files will cause consumers a lot of
> > confusion. 

Yes, that is clear.

> > 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.

Yes, this pattern has already been seen with for example CGM, which
suffered that problem for years.

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

As a counter argument, a bunch of SVG-specific, SVG-only technologies might
make standalone SVG file seasier to render in the short term but would
really suck when it came to integrating them with other things. And its the
SVG + MathML, or SVG + XHTML, or SVG + SMIL Boston combinations that start
to look really interesting.

> > 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, 


While certainly appreciating what you have to say, i point out that
sometimes fewer languages is not easier. For example we chose to use XML,
and this has no Linking mechanism so we also chose to use XLink. Thats two
specs. But since we needed a syntax and we needed linking, making up a
single "xml-lite-like-with-linking" would not necessarily have helped in
the short term since it would need to cover the same ground, and would have
been detrimental in the longer term.

> > and SVG will
> > work well as an interchange format as well. 

I do observe that Stylanble SVG with CSS can be imported and exported by
several existing tools. Its not full round tripping yet, but i know some
implementors are working towards that.

> > Companies
> > that have expertise in graphics, but no expertise in
> > web technologies will be able to leverage SVG too.

I think that they can, as implementation experience is starting to
demonstrate; and they are well set up for moving out into a wider,
integrated web too.

> > Two SVGs is a terrible idea.

We are starting to get that message. Actually it wasn't that we though two
SVGs was wonderful, just that it was the best we could do given the
constraints. For exanmple, being able to do graphical styling of SVG with
either CSS or XSL.

--
Chris

Received on Wednesday, 22 March 2000 16:20:41 UTC