Re: SVG Tiny 1.2 is now a Candidate Recommendation

On Aug 14, 2006, at 06:21, Doug Schepers wrote:
> I truly wish we could have made everyone happy, but a specification  
> is a
> matter of compromise, and many commentors had contradictory  
> desires, as well
> as wishes that conflicted with those of people and companies on the  
> WG.  For
> my part, I was very unhappy with a great many of the compromises  
> that, in my
> opinion, reduced the functionality of SVG, but were made to satisfy
> commentors.

To complement Doug's excellent reply, I would like to add a few points.

There is no one set of rules that guides all specifications, and no  
one way of evaluating them. One approach is to compare them to the  
"market" in which they intend to evolve. Seen that way, some are  
exploratory and so far ahead of anything that might ship that they  
either get to pretty much entirely define what will happen, or fail  
to make any mark on reality at all. Others are post-facto  
descriptions of what minimally works out there, and document that in  
order to provide convergence and solid grounds for following  
versions. A great many are somewhere between those two extremes. SVG  
is one of the latter.

The fact of the matter is this: SVG Tiny 1.2 implementations are  
starting to ship. We could either define what those will have to  
interoperate to, or we could give up and come back two years from now  
and make a post-facto specification of what will have been out there  
at that time. But anything between the two would have been an  
exercise in futility — the spec would have ended in that special  
limbo that sits between the moment when you have a chance to  
constrain upcoming implementations, and that where you are  
documenting what works across those that have been released. If we  
hadn't shipped now, we could have disbanded for a spell and two years  
hence you and I and others would just be figuring out whatever the  
leading implementations are doing.

Another way of looking at specifications is divided in a manner  
similar in which evaluation other countries in foreign policy is. You  
can look at a static snapshot (Are they good/friendly/smart, for  
whatever value of those words you wish to have), or you can look at  
the dynamic picture (Are they getting better/worse, friendlier/ 
fiendier, smarter/dumber, etc.). I find the latter generally more  
useful.

I've spent a fair amount of the past four years working on this damn  
spec, and more than that using the stuff. I can tell you that if it  
were up to just me and me alone, there are things that I'd do  
differently, and some I wouldn't do at all. Yet, SVG has a history.  
There are flaws, some of which have to be continued in order not to  
break content. But we fixed a bloody darn effing lot of them. Where  
you think SVG stands between the Ultimate Good and the Evil Bunnies  
marks is up to you to make your mind up about, if you're interested  
in the static evaluation. Where 1.2 stands compared to 1.1, in terms  
not of features but of quality, is way, way ahead. It ain't perfect  
but it's moving in the right direction. Honest, that's more than what  
I can say about pretty much most of the rest of the world.

Yet another way of looking at a specification is within the context  
of the technologies that it has to compete with. It's a direct factor  
in how one plans releases. SVG, while delayed willingly for quite  
some time to handle comments, does have to compete against Flash Lite  
and MPEG-4 LASeR. Some specifications are lucky enough to know little  
or no competition but those two are serious buggers. The former is in  
the process of launching an all out attack. Large parts of the  
industry are still dubious, but the authoring tool argument is making  
its way. The latter is more pernicious in its ways: they claim full  
compliance with SVG Tiny 1.2 (heck, at 3GSM they claimed to support  
SVG 2.0...), but introduce all manners of incompatible changes and  
extensions. So SVG isn't perfect for purposes of implementation  
within HTML UAs, and that sucks, I much agree. But is SWF, which  
can't be mixed with HTML at all anyway, any better? But is reverse- 
engineering LASeR incompatibilities, which are just about as random  
as it can possibly get (don't take my word for it — read the spec),  
any better? Competing with those means shipping, and it also means  
shipping with some features that go beyond a cleaned-up SVG Tiny 1.1.  
As someone who's been in the trenches of mobile SVG usage in the past  
few years, I can tell you it's not a happy state of affairs. But I'll  
rather ship SVG Tiny 1.2 any day rather than go to the mattresses on  
this one. I know and have used the alternatives — I prefer imperfect  
SVG over them even with the hangover.

Now, I know there are grievances that haven't been addressed as well  
as they could have been, and sometimes not at all. People think that  
WGs have endless resources, but at the end of the day a WG is pretty  
much exactly like an Open Source project, except that the only people  
to whom you can really say "patches welcome" are the folks who are on  
the group. You state that one shouldn't need to be on the WG in order  
to influence the standard, and you are entirely right. That's the  
entire point of having an open (to varying degrees) specification  
process. But even with the best of comments — and I'm not being a  
polite sycophant when I say that the comments we got from all of this  
list quite simply kick ass — you'll only get as much as there are  
resources to get something done. Heck Maciej, you write software, you  
know what a release is about. Safari 2.0.4 (419.3) still doesn't seem  
to know that attributes without a prefix are in no namespace — do you  
really expect SVG Tiny 1.2 to be perfect? I am well aware that the  
parallels between software and specs only go so far, but they do hold  
to a point. If you'd waited until you supported everything perfectly  
right before shipping would you be where you are today? We have the  
same problem.

This release of SVG:

  1) guarantees better interoperability than if it wasn't here
  2) is much more implementable than previous versions
  3) stands a solid chance of pushing an open standard for vector  
graphics against the pressure of proprietary formats such as SWF and  
LASeR

Am I satisfied? No, but then I probably won't ever be. But I reckon  
it's as good as it could get given the situation, and I'm happy about  
that.

And since in the very close future I will likely be fairly less  
involved in standards than I am now, I would like to conclude here by  
saying that working with the people on the SVG WG has been an  
extraordinary experience. I wish to have the chance to meet such  
excellent and kind people in other walks of life. I have no doubt  
that SVG, while indeed imperfect and yet kicking ass, is in the best  
of hands.

-- 
Robin Berjon
    Where do we go from here?
    Why is the path unclear?
    When we know home is near
    Understand we'll go hand in hand
    But we'll walk alone in fear
    Where do we go from here?
    When does "The End" appear?
    When do the trumpets cheer?
    The curtains close
    On a kiss god knows
    We can tell the end is near
    But tell me, where do we go from here?
    (Hey, nothing beats a Buffy reference :)

Received on Monday, 14 August 2006 06:52:53 UTC