From reading the spec, the problem with SVG is that it is very difficult to implement completely due to the all-encompassing rendering model, javascript integration and animation scripting. This makes it difficult to read and write, without pulling in half a browser, and next to impossible to edit fully, unless using a text editor.

So if we do see more adoptions, it's quite likely they'll either end up incompatible with each other or some consensus on a work-able subset of SVG is reached.

Perhaps if W3C had done a reference implementation much like, say, H.264 has reference implementations, some of this could have been avoided?

I'd enjoy reading opposing views on this, interesting topic.

http://www.w3.org/Amaya/ is a kind of reference browser from the W3C. The release history lists the first SVG support in Amaya 4.0 from 10 November, 2000.

Amaya does not render correctly the most basic SVG files. Even IE6 would make a better reference implementation of web standards.

Batik seems to be the most well-tested and conformant implementation of SVG at the moment: http://xmlgraphics.apache.org/batik/status.html, though I would use WebKit as reference because of it's market share and potential of Google and Apple to change the SVG spec.

Yes.

If it was going to take off in a big way it would have.

Would have been much better off if the spec was 10% the size and covered 95% of the use cases rather than the actual monstrosity which almost nothing fully implements correctly.

May I know which applications/start-ups do you mean? I'm working on a web-based SVG editor myself because I was unable to find such tool on the market. I can only think of SVG Edit which is unlikely to be ever usable considering how messy its code is.