XP and XML
by Eric van der Vlist
|
Pages: 1, 2
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.
- XP and XML are not incompatible; but XML drifted
2003-04-17 15:26:56 Andy Glew - XP and product development
2003-03-16 17:00:17 Naren Chawla - To a man with a hammer...
2003-03-09 22:27:27 William Pietri
