Shortly after the XML standard has been released, a plethora of communication related technologies appeared that were based on it: XML RPC, XSD, WSDL, UDDI. There was great optimism following the release around year 2000 and the industry envisioned a world in which computer to computer communication would soon become commonplace enabled by such technologies.

But in spite of their effectiveness in structuring information, the enormous number of business supporting them and unprecedented consensus with regards to the direction of technology, these standards failed to deliver that promise. The reason why, has nothing to do with structure and everything to do with how meaning is seen in the world of computation.


The Extensible Markup Language (XML) appeared out of the necessity to be able to exchange richly structured documents over the web, akin to HTML, which was too rigid for this purpose, having predefined tags and as such being limited to a certain kind of data. The general structure of an XML is very similar to the HTML counterpart example: 18.

  • Example 18, Person structured in an xml file
  • <Person>
    	<name>John Doe</name>
    		<street>Elm Street</street>


As opposed to HTML, XML can encode virtually any kind of information, because the tags are not standardized. XML however, was never meant to carry any semantics. In an article, A Technical Introduction to XML (Walsh Norman, 1997) was writing:

“XML specifies neither semantics nor a tag set. In fact XML is really a meta-language for describing markup languages. In other words, XML provides a facility to define tags and the structural relationships between them. Since there’s no predefined tag set, there can’t be any preconceived semantics. All of the semantics of an XML document will either be defined by the applications that process them or by stylesheets.”

Quote 2, Walsh Norman, 1997

Owing to this absolute freedom for structuring there is no way to tell what actually is encoded in the XML itself. In an XML, the tag <name> does not mean anything; it could just as easily be <eman>1 or anything else. This meant that there was no way for two applications to exchange information this way unless they agreed to rigid structures by ways of which they encoded and decoded the information. To put an end to the confusion and to allow a more general use to the XML, the XSD standard was defined, which is in turn an XML structure meant to standardize definitions in XML format.


Published in 2001, the XML Schema Definition (SXD) is a schema language which allows for the definition of restrictions in the structure of XML documents such that there could be some general common ground in the definition of types during information interchange via the web. Being specially thought up with type definition in perspective, the XSD standard also defines the basic data akin to most programming languages: String, decimal, dateTime, time, float, double, etc. (19 total) and XML schema elements that allow for construction of structured types, example: 19, like Person or Address from example: 18.

  • Example 19, XSD schema example
  • <?xml version="1.0" encoding="utf-8"?> 
    <xs:schema elementFormDefault="qualified" xmlns:xs=""> 
    	<xs:element name="Address"> 
    				<xs:element name="Recipient" type="xs:string" /> 
    				<xs:element name="House" type="xs:string" /> 
    				<xs:element name="Street" type="xs:string" /> 
    				<xs:element name="Town" type="xs:string" /> 
    				<xs:element name="County" type="xs:string" minOccurs="0" /> 
    				<xs:element name="PostCode" type="xs:string" /> 
    				<xs:element name="Country" minOccurs="0"> 
    						<xs:restriction base="xs:string"> 
    							<xs:enumeration value="IN" /> 
    							<xs:enumeration value="DE" /> 
    							<xs:enumeration value="ES" /> 
    							<xs:enumeration value="UK" /> 
    							<xs:enumeration value="US" /> 

Unfortunately this additional layer of structuring still doesn’t bring types closer to containing any universally evident meaning. With all the effort that was put into it, the XSD only brought the global data type definition to the point where all the programming languages already were, with the added benefit that this time there were no programming language dependencies and the definition language is universally accepted.

◊ XML-RPC, Web Services and the UDDI

XML – RPC stands for (XML encoded Remote Procedure Call) which is a way of invoking functions (methods) in an application from a remote location.

There are obvious complications with invoking methods remotely, the most obvious ones being that the remote machine does not have access to local pointers, stack, memory, type definitions, and so on, so an RPC mechanism is designed to encode all necessary information into a network message on the consumer, transmit it to the provider, decode it, interpret it by matching it to a local call, obtain a result if necessary, encode it and send it back to the consumer. These providers have become known in the modern networking systems as Web Services, and are very similar to the concept of the object in OO development, comprising a set of functions that can be invoked by potential consumers, but in this case, over a network.

Abstracting from the intricacies of the implementation of RPC systems it can be seen that together with WSDL (Web Service Definition Language) it is in fact a standardized definition of the concept of interface as understood by most object oriented developers (a definition of functions that must be coded into all classes declaring / inheriting that interface). just as in the case of XSD the definition of these Web Services (objects serving over the web) is independent of any specific programming language.

This independence from programming languages of both type definition and interface definition gave great hope to the IT industry with regards to automating communication between software applications (business to business or B2B). The UDDI (Universal Description Discovery and Integration) registry was supposed to contain a vast collection of such interfaces, published by businesses, and as such all businesses could potentially interconnect and exchange information, example: 20.

  • Example 20, Accommodation search automation
  • An application could consult a UDDI and automatically discover all applications that offer room for rent at “Destination XYZ”, and consult whether they conform to certain criteria: star category, price range, etc.

The reality proved different, in spite of unprecedented support from all major players in the industry. By 2010 most of them were retracting support due to lack of interest and adoption and the concept of UDDI was dead.

  • 1, Name written backwards