Scalable Vector Graphics (SVG) is an XML grammar for describing rich 2D graphics and is a work of the W3C. The Batik Apache project (see http://xml.apache.org/batik) is an open source, Java language based toolkit for generating, manipulating and viewing SVG content. This paper shows from an implementor point of view, the feedback of the Batik software engineers while implementing the SVG, DOM and CSS specifications.
This paper first introduces the problems and difficulties the Batik engineers encountered while implementing W3C standards. Then, it presents what potential contributions the Batik team can provide to help the W3C QA activity.
Batik is an Apache open-source project. Under the umbrella of the Apache project, individuals from companies such as ILOG, Kodak, and Sun Microsystems decided to provide a Java based toolkit that let developers create, manipulate, transform, or view SVG content both client and server side. This part shows the feedback of the Batik team and some of the problems that appeared during the implementation of W3C standards.
W3C specifications are becoming bigger and bigger. Implementing a five hundred pages specification is a huge amount of work so the layout of a specification is critical to help developers in their task. As an example, providing a complete description of an attribute (its semantic, if it is required or not, its default value if any, the authorized values, when to go in error...) is quite common in W3C specifications and often consists of several paragraphs.
Here is quick list of items that illustrates the various problems encountered while implementing the SVG specifications in particular and the W3C specifications in general.
To see if an atribute is required or not, developers have to read the DTD fragment which is often located at the top of the element description (not close to the attribute definition).
Sometimes, an attribute A describes in addition to its semantic, the semantics of attributes B, C and D. The description of the attributes B, C and D then references the description of attribute A and overrides some part of the specification such as the default value for B, when C go in error... With such a description, developers must navigate through the attributes description and extract the correct informations for each attributes.
It is common in W3C specifications that, while reading an attribute description, readers have to follow two or three hyperlinks to have a chance to read the complete explanation of this attribute. Abusing of hyperlinks makes the specification more complicated to read.
One of the first QA activity's goal could be to work in collaboration with the various working groups to design a common and 'developer-friendly' layout for the W3C specifications. The Batik team is willing to contribute or give feedback on this project if needed.
For instance, the matrix in appendix [A] summarizing informations that would be helpful.
Today, people expect software components to be interchangeable. Sometimes, a specification does not specify the exact behavior of a particular feature or let the implementations do what they want. The Batik team was confronted with this problem and it was sometimes really hard to make a choice.
As an example, the DOM Level 2 specification does not specify how an implementation must react if null is specified for the 'qualifiedName' parameter of the createElementNS method of a Document. The specification does not say if it is an error or not either. An implementation can choose to go in error (throwing a NullPointerException for example in the Java language) or return an element with no qualified name. In conclusion, a user can easily write a programm using the DOM and have different result depending on the implementation he uses.
'implementation dependant' or unspecified behaviors are really dangerous as far as interoperability is concerned. When a working group does not find a solution and plan to let a particular behavior or feature unspecified or dependant of the implementation, perhaps the following question will help:
Considering now that two implementations are doing different things, is it important for users or not?
May be, the answer is 'no' and the feature can be kept as is. Otherwise, the working group can decide to specify the behavior even though a vote is required. The answer could also be: "It is an error" and what error is it, could just be a highlevel description such as the one in the SVG specification. In any case, it will be one of the QA activity's biggest challenge.
This SVG working group has spent a lot of time working on the SVG Conformance Test Suite. The Batik team fully supports this initiative and has contributed to the evolution and the validation of this test suite. During the development process, it is clear that the test suite was (and still is) really valuable for Batik. It was an easy way to see if the SVG implementation of Batik was doing the right thing. Many times, we raised issues or start discussions based on a particular test for example. Each time, issues have been resolved and the specification clarified, simplified sometimes or illustrated via screenshots or additional examples.
The Batik team thinks that test suites are really valuable at any step of the specification process. In working draft, the test suite provides an easy way for implementations to check if they are doing the right thing and see what part of the specification has to be improved. In Candidate Recommendation, it helps developers to give feedback to the working group, ask questions and show the working group potential problems. Finally, when the test suite is released publicly (as of Candidate Recommendation status for SVG), the test suite helps end-users understand the SVG features and see the current status of each implementation available on the market.
In conclusion, the Batik team had a really good and valuable experience with the SVG Conformance Test Suite. Starting developing test suites in working draft is certainly a major feature to consider for the W3C specifications to come.
The Batik team has developed its own SVG test suites which is already available for download on the Batik web site. The goal of this test suite was first to validate the SVG implementation of Batik and then to illustrate the current implementation status of the SVG specification. Those tests, developed by the Batik engineers, are not exhaustive in terms of SVG features but represent a good stress case for a particular feature. Those tests are also used in our regression tools, just to detect if a regression appears while implementing new features.
The Batik team is willing to contribute its test suite to the SVG working group in order to improve the conformance and the interoperability of both the SVG implementation of Batik and the other SVG implementations available on the market. Of course, if the other teams implementing SVG also contribute their tests, the interoperability could become real.
In addition, some Batik engineers could collaborate with the new Testing and Quality Assurance Activity to provide suggestions, tips, tests, testing tools or comments as far as the W3C specifications they are currently implementing are concerned or more if needed.
Finally, ILOG is interested in trying to make its internal QA process as compatible as possible with the future QA methodology and tools of the Testing and Quality Assurance Activity at W3C.
In this paper we have presented, from an implementor point of view, the feedback of the Batik team. We have seen that both how a specification is layouted or how informations are described may improve or not the global comprehension of the specification. Finally, we have discussed the benefits of test suites and see that they represent an opportunity for both developers and users.
The Batik team is really interested in the new Testing and Quality Assurance Activity at W3C and will be happy to contribute existing works such as its test suite or participate to discussions as far as Quality and Assurance is concerned.
Thierry is a software engineer, at the Koala project of ILOG located at INRIA Sophia Antipolis, France. Thierry has contributed to most of the Koala's projects involving Java and XML. Since then, he co-founded the Batik Apache project. His daytime job is focused on Graphics and XML related technologies.
An example which represents a matrix that could help developers to implement the Filter element of SVG.
|