XP and XML

February 19, 2003

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.

20 Second Guide to Extreme Programming (Part 2)

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:

Planning Process: the planning is based on the description of elementary features (the "user stories") which cost is evaluated separately (and re-evaluated as many times as needed over the course of a project).
Small Releases: a simple version of the system is released at an early stage and frequently updated.
System Metaphor: the naming conventions are standardized.
Simple Design: the design should be the simplest possible to meet the current set of requirements.
Testing: tests are essential; unit and acceptance tests are written before the code and new tests are added for each bug found.
Refactoring: the system is continuously revised and duplications of code are removed.
Pair Programming: the code is written by pairs of programmers working on the same machine.
Collective Code Ownership: any code segment belongs to the whole team.
Continuous Integration: the system is built and integrated several times a day.
40-hour Week: developers are kept "fresh, healthy, and effective".
On-site Customer: the customer is an integral part of the project.
Coding Standards: everyone must write the code in the same way.

What XML could do for 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.

Planning Process

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.

System Metaphor

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.

Testing

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:

Test data can be edited, making it easy to add additional test cases;
test data can be validated, as a means of reducing "false failures"; and
test data can be externally generated or captured from a production process.

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.

Refactoring

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

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:

An increasing number of employees now work from home. This trend is dramatically reducing the time lost in physical commuting and the office square meters needed by the companies to keep all their employees in a single location. It is usually seen as an improvement of the working conditions.
Companies are more and more interdependent either because some tasks are externalized and subcontracted to other companies, which may be located on the other side of the planet, or because they build partnerships to cooperatively develop projects which are too big for one of them.
Open source projects are becoming part of the strategy of major players in the IT business, and they group employees from different companies at different locations together with independent consultants, students, and other volunteers often working by their own.

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

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.

Coding Standards

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.

Summary

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.

XP for XML

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".

Simple Design

To put it bluntly, XML itself is anything but simply designed. Its complexity is due to two main reasons:

The XML infoset, the "meaningful" information found in a XML document, has been defined independently of any programming language. Its structure has no natural fit in any of the built-in types of the programming languages, leading to APIs which are not as simple as they could be. The consequence is that for simple things, such as parsing a simple configuration file, it is simpler (not much simpler if you're familiar with XML APIs, but still simpler) to use more trivial mechanisms than to rely on XML.
XML has given birth to a bunch of related specifications, and both the number and the complexity of some of them do not qualify as simple design.

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

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.

Testing

Why should unit and conformance tests be more difficult in XML? Two reasons:

Application-dependent syntactical variations are allowed in XML serializations, which make even the simplest tests much more difficult.
New languages have been defined (XSLT, W3C XML Schema, Relax NG, Schematron,...) creating needs to new unit test systems.

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.

Summary

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.)

Conclusion and Acknowledgments

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.