XP and XML
I discovered Extreme Programming (XP) in April 2001, at the SD West conference, through a workshop by James Grenning and Robert Martin and a presentation by Chet Hendrickson and Ron Jeffries. Since then I have been vexed to see that XP is out of my reach for two reasons. First, I am mostly interested in XML applications, and XML isn't that great when you are using XP practices. Second, and more irritatingly, I work remotely from home and this is absolutely not XP kosher.
However, the more I think about it, the more I am convinced that both XP and XML could benefit from working more closely together. And there may even be some hope for remote pair programming. I can't pretend to have real experience with XP but only with some of its practices, which I have been able to follow despite my remoteness. Therefore, most of this article is theoretical, but I hope that these ideas will still be useful.
The links between the XP and XML communities were covered last year in an XML.com article by Leigh Dodds, "XP Meets XML". I will cover the technical relationships between XP and XML in the remainder of this article.
I am not proposing to compare apples and oranges: I know that XML and XP don't share anything except the fact that they are young concepts defended by quasi-religious communities. Even the superficial name similarity is misleading: XP stands for eXtreme Programming, while XML stands for eXtensible Markup Language. XP and XML don't even operate at the same level: XP is a methodology and XML is a technology. That said, I like both and they don't seem to be incompatible. Leigh Dodds has shown that if XP zealots could find XML too complex to be "extreme", XML users are more inclined to be "extreme". My goal is to explore in more detail how these acronyms play together: how XML as a technology might help XP programmers, and how well XP as a methodology is adapted to developing XML applications.
I won't introduce Extreme Programming again, so please consider this to be the continuation of "10 Second Guide to Extreme Programming" in Dodds' article. In addition to Dodds' guide, we need to say a word about the "twelve practices" that are the foundations of XP:
The XP practices rely heavily on communication between team members and a fluidity of the code that is continuously refactored. Communication and fluidity are where XML excels. One might think that implementers of XP tools and even XP users would have been eager to use XML pretty much everywhere. This is not really the case and even though a few XML applications have been developed for some practices, I haven't found any cross practices effort to define a XML framework that could facilitate XP as a whole.
Being feebly tooled appears to be a more general characteristic of XP. During my research I was surprised to see that there doesn't seem to be an "XP IDE" taking care of the twelve practices; on the contrary, XP developers rely on conventional tools: text editors, browsers, CVS repositories, Wiki-wiki webs, instant messengers or IRC. The two practices which are the most advanced in terms of tools are probably testing, with the development of the "xUnit" test frameworks, and refactoring, traditionally strong in the Smalltalk world, which has greatly influenced XP.
Is it the influence of the "Simple Design" practice which recommends never writing any piece of code "for the future" if it is not immediately needed? This principle is pretty much a killer for the development of tools, which by definition are written to be used in the future. Or is it because XP defines itself as the mindset to bring best practices up to their extreme more than a methodology and a mindset isn't a matter of tools?
Whatever the reason, the fact is that very little effort seems to have been put into even integrating these traditional tools, not to mention developing a complete IDE for XP developers. If there are few tools and little integration, there are few opportunities for using XML.
As a remote worker, I can't pretend to have ever practiced XP. Even though I am not a XP specialist (or maybe because I am not one), I would expect benefit to come from better tools and integration, especially in the "Planning Process", "System Metaphor", "Testing", "Refactoring", "Pair Programming", "On-site Customer" and "Coding Standard" practices.
The basic atom used by XP's Planning Process is the user story. The definition of the user story is pretty simple. Ron Jeffries has said that "a User Story is a story, told by the user, specifying how the system is supposed to work, written on a card, and of a complexity permitting estimation of how long it will take to implement." User stories have also been defined as being "in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax."
This seems so simple that it would hardly deserve an XML "techno-syntax", but it's only one piece of the problem. Other information needs to be added such as scheduling information and acceptance tests. The fact that we need to glue all this together and eventually associate the engineering times consumed to implement the story, and later keep a track of the origin of each acceptance test, is a good call for something more formal which could be implemented in XML.
An XML-based proposal (PDF) has been made by Karin K. Breitman and Julio Cesar Sampaio do Prado Leite which covers not only the user story (called a "scenario") but also the description of the actual task of implementation and a glossary which could be used for establishing the naming conventions needed for "System Metaphor". Unfortunately, this proposal doesn't seem to have got much traction. Among the benefits of this approach, the authors note the consistency checks which can be done on the user stories when they are expressed in XML should improve their level of quality.
Already mentioned in Breitman and Leite's proposal, the system metaphor is also something which can be formalized. Any format could be used and the glossary might be stored in a RDBMS, a spreadsheet, or a CSV document. However, formalizing it in XML would give the flexibility to publish it on various medias and enable consistency checks with different documents including user stories.
XP defines two different types of tests: acceptance (or functional) tests, which test a user feature "end to end" over the complete system, and belong to the users or customers; and unit tests, which test the behavior of a single class or function and belong to the programmers.
For the acceptance tests, a XML format would seem interesting, especially if they are attached to user stories which are themselves expressed in XML. The case for using XML is probably stronger for acceptance tests than for unit tests, because acceptance tests are owned by the customer. It seems like a good idea to decouple the way to express these tests from the technologies and languages used by the implementation.
Outside the scope of XP, many test suites are written in XML,
but they appear to be pretty specific to each application. With
Relax NG for instance, James Clark published a test suite as an
XML document including a set of schemas, either valid or
invalid, and for each valid schema a set of valid and invalid
instance documents. If Clark had defined the test suite using
jUnit, the unit test package for Java, the language he has used
for his implementation, it would have been tough for me to use
it to test my Python implementation. Since it is expressed as
XML, this test suite is easy to use to generate documentation
and individual documents which can be processed using generic
unit test libraries (in my Relax NG implementation, XVIF, I use the unittest package to perform the actual
testing).
Even though such test suites will likely remain specific (you don't define the tests for a schema language in the same way than you define the tests for a user interface), at a high level there are many invariants in a test definition: one or more inputs are processed to generate one or more outputs which are compared against expected results. It should thus be interesting to define an extensible vocabulary to express these invariants.
This is more or less what has been proposed by Bill la Forge in JXUnit, with a focus which is more on unit tests than on acceptance tests. In a nutshell, JXUnit is the integration of a XML binding framework together with jUnit. Test cases are expressed as XML, the Java objects are created by the binding framework, and jUnit is called to perform the tests. Bill la Forge sees the following benefits to separating the tests from the code, and these benefits apply equally very well to acceptance tests:
The case for separating test data from the code is weaker for unit tests, unless one tried to combine the paradigm of XP with Literate Programming, another methodology which I find very promising. As proposed by Norm Walsh, "Literate Programming in XML" stores in XML fragments both the documentation and the code of a program unit. In such a context, this fragment could be extended to include the definition of the unit tests for the same program unit. Grouping each unit of code with its documentation, tests, and source in a format which is easy to process with XML tools and can be stored in a repository seems really powerful.
Along with unit testing, refactoring is the second practice where a number of tools are available. Support for refactoring is integrated into many IDEs and they seem to do pretty well without XML. That said, if we had implemented the "eXtreme Literate Programming" framework mentioned above, evaluating the impact of a refactoring would be much easier since the relations between code units would be formalized as XML. Code units would contain the source, tests, and documentation grouped together, and the relations between code units and conformance tests could also be formalized to evaluate the possible impact of a modification of a unit of code on the system.
Pair Programming, or at least face to face pair programming, is the most restrictive XP practice since it goes against three major trends in Western society:
These three trends mean that it will be increasingly restrictive to require that all the members of a team are located at a single location, the prerequisite for face to face pair programming, and that virtual pair programming will become a necessity.
The concept of virtual pair programming isn't new and many papers have been written on the subject. Pair programming can be implemented without XML using standard conferencing tools. However, I think that using an XML infrastructure to build the support of pair programming into the IDE itself could make the concept of virtual pair programming fly.
Some will argue that text based conferences are not sufficient for effective virtual pair programming and that voice and even video is needed. I am not convinced: daily use of IRC makes me think that simple text based conference systems are enough to let you "see" what your partners actually "think". Even if I am wrong. one can always complement the built-in collaborative features of an IDE with traditional audio or video conferences. The reverse seems to be less obvious, and I am not that sure that the generic file or desktop sharing features of audio or video conference systems can be as well adapted to virtual pair programming as the collaborative features of an IDE.
|
Several tools are already including (or developing) this kind of feature. In the world of XML editors and IDEs, there is the Topologi Collaborative Markup Editor, with its SOAP based peer to peer functionality; also, XML Cooktop and its Jabber based peer to peer features. The Eclipse open source IDE project lead by IBM, particularly its koi infrastructure, have a goal to "serve as a test bed for collaborative Eclipse Workbench plug-in functionality," using XML-RPC.
These independent efforts, using different XML protocols, suggest we have all the building blocks needed to implement a "pilot mode" in our editors which would let you see what your partner is typing and leave you the option of leaving an instant message to give your feedback.
On-site Customer suffers from the same problem as pair programming; getting the customer on-site is nice, but getting her or him physically on-site is too restrictive in many cases, leading to a lack of on-site customer, which is usually solved in XP project by a Customer Proxy, i.e. a member of the development team with a privileged contact to the customer and acting as its representative.
After what we've said about virtual pair programming, an option which seems interesting to explore is the "virtual on-site customer", i.e. a real customer working remotely. The tools to use should be more or less the same as those needed for virtual pair programming.
Because an important part of the role of the customer is to answer questions, in this role collaborative editors are not necessary and may be replaced by a traditional text, audio, or video conference system. The text option should be considered seriously since even though the exchange is poorer than with audio or video, the exchange can more easily be archived and indexed.
Other parts of the role of customer, such as editing user stories and acceptance tests, would, however, gain some advantage from collaborative editors similar to those used by virtual pair programming.
Last but not least, formalizing coding standards as XML would give pretty much the same benefits as we've seen with the glossary of the system metaphor: it would enable the publication of the standards on different media. Also, especially in a context where coding information is available as XML, it would give the possibility of automatically checking if the rules are followed in the project.
I think that it's quite obvious that if XML can justify itself on some of these practices, the killer application of XML would be in the interaction and interoperability between the practices. It is well known and documented that the twelve practices are very interdependent and that the benefit of using them together is greater than the sum of the benefits of using them separately. Generally speaking, XML's main benefit is in interoperability between distinct yet dependent applications, and this is exactly how it would best be used here.
Let's look at the other side of the coin and see what problems are specific to XML applications when following an XP methodology. I think that we have both conceptual issues, dealing with "Simple Design" with a side effect in "Refactoring," and more practical issues dealing with "Testing".
To put it bluntly, XML itself is anything but simply designed. Its complexity is due to two main reasons:
Following the Simple Design practice, XP programmers must choose the simplest possible design to meet the current set of requirements and that's certainly a brake on using XML. The answer could be to continue to work toward simpler APIs -- less generic but better integrated in the various programming languages or even to add built-in types to match the XML infoset. Also there ought to be more utility packages "hiding" XML from the programmers when performing some specific tasks.
Such utilities could be for parsing a XML configuration file, but there are other domains where the flexibility and complexity of XML would be better used; for instance, the persistence layer which is needed by most XP projects. Simple tools such as JSX that provide transparent serialization and class evolution features could have a role to play.
Refactoring can rapidly become painful if your system is using a wide range of XML technologies. Let's say we have developed a XML application with a writer and a reader in Java to serialize and deserialize information as XML, an XSLT transformation to present the information on a web site, a schema (Relax NG, DTD, or W3C XML Schema) to validate its structure, and another one using Schematron to check some "business rules", and finally a XForms form as a UI. The impact of simply changing the name of an attribute or adding a new element will obviously be higher than if the application had been fully implemented in Java and things grouped in a single class.
The additional complexity comes from the fact that several languages need to be mastered. There isn't much we can do about this. Complexity also comes from the fact that it's easier to refactor a system where things that belong together are kept together, instead of being spread out in several documents. This second source of complexity can be compensated for by grouping code by function rather that grouping it by language. This was one of the motivations in my proposal to embed transformations and validations (xvif); and it would be easy too with our "eXtreme Literate Programming" framework.
Why should unit and conformance tests be more difficult in XML? Two reasons:
The first approach that comes to mind when testing that a XML
fragment sent back by a function or method is what's expected is
to test the serialization of this fragment as a string against
the expected one. If I am expecting an empty element "foo" with
two attributes "bar1" and "bar2", we would thus test that the
string is <foo bar1="1" bar2="2"/>. The
problem is that most applications will consider this to be
equivalent to <foo bar2="2" bar1="1"/> or
<foo bar1='1' bar2='2'/> or <foo
bar2="2" bar1="1" />. Depending on the "writer" used
to serialize you XML, you can get one or the other.
These equivalences are defined by the XML 1.0 recommendation and
this means that string comparison isn't portable: if we use them
we have a risk of detecting false failures if we change or
upgrade the "writer" used to serialize our result. Also note
that if we were writing a XML pretty printer or a
canonicalization library, we would not consider these variations
as equivalent, and that many more equivalences are usual in XML
vocabulary. The value of namespace prefixes, the relative order
of children elements, and whitespace variability are examples of
such variations which are sometimes considered equivalent and
sometimes not, depending on the application. Still worse, for a
given application, these variations can be significant only at
some locations in a document: for instance, in RSS 1.0, as for
any RDF application, the relative order of children elements is
not significant, except within specific elements such as
rdf:Seq.
There are two solutions: you can either define a "canonical" format (i.e., a "normal" form) for your application and perform string comparison on the canonical form or do an application specific comparison on the XML fragments interpreted as DOM trees, SAX events, or whatever representation best fits your needs. Note that in both cases, the canonicalization or the comparison must be adapted to the vocabulary which is used.
That's one of the issues I have found when I developed my Python implementation of "Regular Fragmentations" and the research I did at that time (July 2002) has shown that in the many "XML diff" libraries that are available, their focus is on identifying differences between versions of a document for editing, and that although they can often recreate a version from the differences and the other version, the criteria to determine if two fragments are equivalent cannot be customized.
I have thus developed a very simple comparison library implementing the features I needed at that time, which could serve as a base for a more complete library.
The second difficulty is in defining unit tests for XML specific languages such as XSLT. Since XSLT is a programming language, and since XSLT transformations are modular and may become complex, it is necessary to be able to define unit tests for XSLT templates. That's the purpose of my XSLTUnit framework.
It's interesting to note that these two issues are linked and that XSLTUnit assertions need to compare XML fragments. The current version of XSLTUnit doesn't support the customization of these tests, but that would be a useful enhancement.
To a lesser extent, there is also a need for unit testing with other languages: XQuery obviously, but even schema languages. Schemas are usually more complex than the instance document, and it might be worth being able to test that a Relax NG pattern, a W3C XML Schema complex type, or a Schematron rule does not go wild, and actually does what its author is expecting.
The issues we've seen in this second part do not seem unsolvable. XP can be used right now to implement XML applications and it appears that this is a matter of mindset and tool availability more than any real incompatibility between XML and XP. (It would definitely be nice if XML developers, designers and architects had more of a "XP mindset," and were eager to follow the "Simple Design" practice.)
Although the reluctance of the XP community toward XML noted last year by Leigh Dodds is persisting, there is a huge opportunity to make XML a technology of choice for implementing better tools for XP, and the XML community still has lots to learn from the XP community. I'd like to thank Michel Duperrier for giving me the basic idea behind this article, Nicolas Chauvat and Laurent Bossavit for confirming some of my early conclusions, and Laurent Bossavit (again) for pointing me to JSX and its potential.
XML.com Copyright © 1998-2006 O'Reilly Media, Inc.