Time for Consolidation
June 6, 2001
Is XML changing the way applications are being designed? And if so, what tools do you use to model these applications? The XML-Deviant considers these questions following a lengthy XML-DEV discussion.
The Post-Schema-Delivery Period
As Edd Dumbill noted in last week's XML-Deviant, the XML Schema specification may have been delivered, but the discussions are far from over. The Schema Working Group have delivered a meaty specification, and it will take some time for developers to digest. Expectations have already been raised about the features that may be delivered in Schema 1.1, and the prospect of Schema 2.0 has already been considered.
It's premature to begin thinking too much about what these specifications might encompass until there's sufficient Schemas experience to allow it to be assessed. We must not forget the continuing work on other schema languages, most notably RELAX NG, the unification of RELAX and TREX being carried out at OASIS. Michael Fitzgerald observed that it's "some of the more important work happening in XML now."
Rick Jelliffe, a strong advocate of a plurality of schema languages, characterized the current situation as an interim period, and XML Schema 1.0 as a "provisional" specification:
[Any] standard for schemas must be considered either premature or interim, at the current time. And this is exactly the approach that the XML Schema WG has taken: XML Schemas 1.0 is provisional both in small matters (because of the work of XML Schemas 1.1) and in larger matters (the mooted XML Schemas 2.0).
In the same posting, Jelliffe later described RELAX NG as the unofficial research lab of the XML Schema Working Group:
I don't see RELAX NG as a competitor to XML Schemas; to the contrary, I think we can only ascend to XML Schemas 2.0 when there are credible alternative languages developed and deployed, by which we can judge XML Schemas 1.n. (It is dialectic development.)
So RELAX NG is the best friend of the XML Schema WG, in the long run: it is their unofficial research lab...
RELAX NG may be just as important for XML Schemas 2.0 as the XML Schemas 1.1 standards work. But I hope deployment experience from XML Schemas 1.n will be much more influential than any speculative analysis: I think speculative analysis is the methodology used both in XML Schemas and RELAX NG and ultimately it provides no guarantee of producing a productive result. When a spec is made by committees sitting around the globe making up user requirements on the spot as needed to justify their technological and aesthetic predilections, with no regard for how humans think and act, the emperor has no clothes, no matter how relaxing he may find it.
Whatever your opinion of XML Schema, it is certainly a major milestone in the history of XML development, and as such it merits the community taking time to appreciate its impact. No doubt there are also lessons to be learned from the means of its delivery.
Len Bullard summarized this quite succinctly:
XML Schema is approved and out the door. Apply it and report problems uncovered in application.
Bullard also expressed concern that there are so many "meta specifications". i.e. technologies that can be used to model and design systems: XML Schema, UML, RDF, Topic Maps, etc. Bullard was concerned that it's not clear to the application designer the areas in which each should be applied or in which they complement one another.
We are staring into UML, RDF, Topic Maps, XML Schemas, now add RDDL, TREX, RELAX, etc. It isn't that any tool or method alone is hard to grasp, it is the relationships among them and how to choose when one is best. In other words, if we dare to do less, we should use less maybe.
But put it altogether and I think interoperability becomes a statistical guess. Too many casually aligned parts.
Bullard later commented that there are now so many ways to design and model an application it becomes difficult to choose one method over another. For example, should one model applications and document types using UML and then generate the appropriate XML and/or RDF Schemas automatically? And where do Topic Maps fit into the picture? (Not a new question, that one).
Simon St. Laurent didn't think UML was a good starting point for modeling XML documents:
UML may be abstract, but it has roots in modeling methodologies I don't find to be a good fit for XML. XML documents aren't object-oriented programs, whatever some people might think.
Uche Ogbuji believed that RDF is an excellent modeling tool:
... if all you need is expressive modeling, and you are (IMO) realistic about the involvement of programmers and human agents in the design, implementation and maintenance of a system, RDF modeling works very well.
It is just this kind of discussion that is important in "bedding in" any new technology; the relative strengths of each option must be understood before they can be sensibly applied. Jonathon Borden believed that there are presently too many gray areas associated with these technologies to make a clear appraisal. Borden noted that RDF uses URIs and resources ("anything that has identity", according to RFC 2396) which are fairly abstract concepts.
This definition of a resource is basically as abstract as it gets, indeed the problem may be that its _too_ abstract to be practically useful...
Topic maps also get pretty abstract, you have topics which can be anything and subjects which also can be anything (this is a gross oversimplification but if you want to hear the longer version ...) and it gets pretty hard for me to understand what the relationship between a URI, resource, topic and subject really is... so we have lots of people declaring their interest in somehow combining TM + RDF yet no one has been able to write down a coherent and definitive explanation of how these _terms_ related to each other so that whole area is totally confusing...
And then we have XML Schema and its relationship to both RDF and TM and it's been a fairly long day so don't even get me started...
Also in XML-Deviant
Borden advocated taking time out to define these terms and relate them together in a logical fashion, something that he is beginning to do with what he calls a " Schema Algebra."
Pretty esoteric stuff for the average developer though. For many it will be hard-earned experience that will prove to be the ultimate guide toward the best tool for the modeling job. And its here that the community, as ever, plays an important role in sharing and communicating this experience, as Len Bullard wryly observed.
... We sit here daily debating the various technologies we are presented with not to establish polities, name names, bronze shoes, or create new cults of personality. We are comparing our experiences and various backgrounds to come to understandings of the application boundaries of these technologies so we may present to our customers and the net community at large, coherent explanations of how to choose among these.
Entities such as XML.com attempt to make sense of this, and others such as ZDNET proselytize. It does become confusing and when it does, we come back to XML-Dev and discuss what we know, what we remember, and what we believe. Among all that, we tend to sort out the right answers.
And the next day, we do it again. It's all good.
The wider context for this XML-DEV discussion was a wide-ranging debate on application modeling in general, with the emphasis on whether XML, and its attendant schema languages, changes the picture for the systems designer. Jeff Lowery, amongst others, wondered whether a paradigm shift was approaching that might lead to an application's data models being described and constrained separately from its processing model:
If we could, as a practice, declare a data model as a separate entity, along with constraints that can easily be expressed declaratively, along with a type system that supports inheritance, along with default and constant values... **then** hang methods off of those types, along with other processing methods not related to direct data model manipulation, wouldn't we make our lives a whole lot simpler?
An interesting idea, but one unlikely to bear fruit any time soon. That said, there did seem to be a consensus that XML places an ever greater importance on application data rather than code. Uche Ogbuji was one of those advocating a data-centric viewpoint:
Data maintenance is a more important and more risky task than code maintenance. A tremendous side-effect of XML adoption is that it's encouraging developers to finally start putting these matters in the right order.
BTW, I think one of XP's most valuable lessons is that it's not just OK but a valuable exercise to willingly throw away code. The important thing is to be far more careful with data.
More than one contributor remarked that data and data models stabilize very quickly, generally outliving the applications that use them. No great insight, perhaps, but worth noting if only because currently popular methodologies seem to place greater emphasis on the coding process than on data analysis.
This is also no great surprise to those advocating a more loosely coupled approach to application design. The important issue being to package up and ship around data rather than worry too much about how (or who) it's being processed by at the end result, which is a viewpoint that Walter Perry has been expounding on XML-DEV for some time. Loosely coupled systems would seem to be a prerequisite for gaining the most advantage from web services.
At this point in time however there are more questions than answers. Only time spent consolidating our current position will bring any insights. There's a lot to be done to bring tools (browsers in particular) up to speed before launching into further bleeding-edge standardization efforts.