In this ongoing blogessaythesis on substitution, we're going to look at where to find substitution rules or transforms.
The most obvious substitution mechanism is type substitution. Most languages have mechanisms for extending one type for another, and then a substitution mechanism - often called polymorphism - allowing the types to be used in place of each other. We can use the simple example of Type A defines a Name with First name, and Type B adds a Last name to the Name structure.
The tricky part is when one side doesn't know about type B and receives an instance of type B. I've already mentioned that XML Schema extensibility doesn't have a way of adorning an instance of B with the fact that it is also an instance of A, though it could.
As a result, if you want to achieve the scenario where an instance of B can be understand by an A receiver, you need to follow a set of xml extensibility and versioning rules to create the A and B types. This is by no means the only solution, so let's take a look at a survey of substitution mechanisms and architectures that are possible.
1. Use a type system that allows a receiver of a new type to substitute an instance of an old type without any updated information. As mentioned before, this is not built into XML Schema's extension mechanisms of extension, refinement, redefine, wildcard, or xsi:type.
2. Arguably the simplest substitution rule is to make an older type out of a newer type by ignoring the newer type's additional elements. No transformations or alternatives are needed when transmitting the new type. This requires some rules in addition to XML Schema.
3. Send both types and an alternative or fallback mechanism. XSLT provides an if then else and a version test operation. In this scenario, the instances of A and B are provided. The stylesheet has a test version operation. If V2 is supported, then B is used, otherwise A is used. XSLT effectively supports logic of the form: If new type supported then new type otherwise old type.
4a. Send the new type, a transform, and a transform invocation mechanism. The type has a test version operation. If V2 is supported, then B is used, otherwise the transform is applied. Some interesting application architectures are emerging where XSLT transforms are sent in the instance documents to provide this. Now I had thought that there was some semantic web technology to give a transform between types with an instance, but I can't find it. I'll update this blog entry if somebody brings me up to date. For completeness, it's obvious that an XQuery could be sent to do the transform.
4b. Send the new type, a transform invocation mechanism, and a reference to a transform. Instead of sending the transform, send a reference to it. Perhaps a good location would be a UDDI registry.
In either case of 4), the receiver has to decide whether it trusts the sender to give it some executable code, which is perhaps turing complete, or some kind of transformation subset.
5. An intermediary is used to do the transformation, either V1 to V2 or V2 to V1. The receiver doesn't need to change as the intermediary performs the transformation. This seems like a highly useful option and will probably be widely deployed to allow compatible evolution of the services.
There's also the non-solution: The receiver of a newer type simply doesn't know what to do with it. This is an incompatible evolution of the type.
I'm interested in what types of substitution architectures people are deploying and using, whether this is a good list of the solutions, and if any are missing.
Leave a comment