XML has a billion uses in software development. It is being used in everything from persistence to GUI representation, with lots of weird edge cases included in the mix. Personally, I do not like XML, because I can’t read it comfortably. I’ve always seen it as a computer to computer communication mechanism which is readable by humans, when, and if it is absolutely necessary.I won’t go into a long rant about XML, for it would be a little bit unfair, and I do not have a habit of denying reality, contrary to what some clinicians may say about me.

One use for XML you can’t avoid in openEHR implementation is web services.I am talking about SOAP web services (for clinicians, this is Simple Object Access Protocol, this is technical domain, where our acronyms rule, not yours) If you keep hearing things like JSON and REST, well, they have their uses, but for openEHR implementation, I would not really consider using them, because in my view, they are simplification attempts for SOAP web services, which has become a little bit too complex. (actually, a major reason XML web services were created was that CORBA was too complex. Irony that costs billions…)

Now what is the problem with these web services? Well, they are very well supported by free and commercial tools, and they are quite mature. But they are fully XML based. When I say XML based, I mean they require use of XSDs for describing the content, the simple and complex data types that travel over the wire. In other words, two sides of the communication use XSD as a contract for data types and structure of data. Then they use whatever binding they want to use on their side to process this.

I still did not mention the problem did I? Well, XSD is good enough to represent many things, but there are certain aspects of software languages and formal models which can not be represented with XSD in a standard way. In the context of openEHR, the specification makes use of generics, a feature familiar to those who use any non-trivial object oriented programming language. XSD has no concept of generics. openEHR also uses constraints, and XSD has no standard way of representing constraints.There is an XSD on openEHR web site, but that XSD is not a complete representation of the openEHR RM.

This is a big, big problem. The problem gets bigger, since that XSD is being used to develop tools, and it is being used to develop web services. The idea of web services (the kind we are talking about) is representing concepts from programming languages in XML and then transforming them to implementation of those concepts in whatever language you use, when XML arrives to an end point. You have xsd:String as a type in XML world, and you map it to a Java string or  a C# string. You expect to construct something like a composition when XML arrives at your system, and at that point, you have a problem: the arriving composition is based on the XSD that is actually “not” the exact representation of your openEHR reference model. In your reference model, generics are used for example, but in XSD, you have a representation which can reflect the state of the RM once choices related to generics are made. In other words, there is loss of information.Many would say that it is good enough, but what is happening here is we have an on the wire representation of openEHR models that is linked to more conformant  representations (like C# or JAVA classses) in an ad-hoc way.

So the specification is 100% pure representation of what we may model, and C#, Java and Eiffel can come quite close to specification, with Eiffel being almost 100% complete, without much effort. XSD is way behind, since it has no built in way of representing some important aspects of specification, and as far as I know, we are all mapping from this incomplete representation to more complete representations with various methods. Any implementer ends up with a mess trying to do this, and we lose a lot of valuable cpu cycles.

Here is the scenario: XML arrives at the web service end point. It is parsed and values are put into a set of classes instances generated by tools. These classes are based on XML, so they have no notion of things like generics or constraints (sometimes the language can’t event support constraints) . This is reflected into signatures of getter/setter functions and class structures. You need to take these automatically generated class instances and now perform another transformation to put data into your implementation of RM. But your implementation would be using generics, so you have to look at the incoming data, and figure out what choices have been made in using generics. In Java, the implementation of generics is only for compile time, so you can’t even dynamically create instances of generic types in memory, unless you go through an incredible amount of trouble. Even then, certain things are not guaranteed or possible. Anyway, this is actually another issue, not the one I’m ranting about.In short, the expressive power of openEHR specification is weakened pretty much in any case we are using XSDs. There are solutions to these problems, but they do not have the overall elegance of the rest of the implementation of this specification.

I’ll write more on this in part 2.  Till then, take care.