All this week, 6th Sense Analytics (my employer) is hosting the SVG Working Group’s F2F (face-to-face meeting). Normally, the SVG WG conducts its business via email or twice-weekly “telcons” (voice conferences enhanced by concurrent group chat sessions in IRC). But there’s nothing like sitting around a table, locked in a room together, to get resolutions on issues. Thus, the quarterly F2Fs.
So, a contingent of the SVG WG is gathered here in Raleigh (well, Morrisville), NC. We’ve been hard at work knocking out the long-overdue SVG 1.1 Test Suite (more later), liaisons with other standards groups, and other matters.
For dinner the first night, we went to a pub in Raleigh called Hibernian. Our chair, Chris Lilley, entered us into the pub quiz under the obscure (dare I say geeky?) moniker “SVG++”. When the announcer was introducing the teams by names (most of which involved being drunk), he exclaimed, “SVG-plus-plus…? What is that, a disease? Get an ointment for that!”
If you’re really interested in the gruelling details of the F2F, read on…
SVG 1.1 Test Suite
As any QA person will tell you, test cases are as important as they are mind-numbingly tedious. Without a test suite, implementors of a technical specification (like browsers or authoring tools) have no good way to make sure that they are indeed conforming to the spec. As complete as a specification may be, the devil is in the details, and there are innumerable tiny ways that different implementations can diverge. This is well and truly annoying for content authors, who want their page or image to just work across browsers (and rightfully so). Implementors know this, and they have 2 choices:
- Make a guess, and do it the way they think it should be done (hopefully, the way they interpret the spec, but sometimes how they think the spec should have been), and hope that all the other implementors do it the same way; or
- Copy the behavior of other implementations, whether or not it agrees with the spec.
With both options, but especially the second one, you are likely to differ from what the spec says, and so authors just do what works… even if it’s technically wrong. You can’t blame them. This happened with Adobe’s SVG viewer: it did lots of stuff “wrong”, and when Firefox and Opera came along and did those things right, folks found that their content from years back was suddenly broken. That sucked. HTML also suffered from this, and got caught in an downward spiral, where implementors had to support the wrong-but-backwards-compatible behavior that most content authors were forced to code to by implementors that supported the wrong behavior…
SVG is hoping to avoid that by simply moving forward and being more precise in what implementors should do in any given circumstance. This is where the test suite comes in. With a complete test suite that provides reference behavior (especially for tricky bits that are subject to misinterpretation), implementors know where they went wrong, and authors can definitively point out specific bugs that they need fixed.
Of course, this test suite should have been published 3 or 4 years ago, when the last version of the spec was published, and implementors (and vendors) are chomping at the bit for it to be done. But like I said, this is boring and exacting work, so I’m not surprised it got put off when there are tons of other things on the agenda. To be fair, most of the tests were already created long ago, but needed to be reviewed, corrected if necessary (bad tests, as you might suspect, are bad), put into the proper format, and published. But we’re on a forced march to get it out this week, and to start on the SVG Tiny 1.2 Test Suite and the errata for SVG 1.1. More on that tomorrow.