Each tool used for Xml related development has its own tricks, shortcuts, and idiosyncracies. One such tool is XmlSpy©. Anyone familiar with this tool in the context of Xml Schema creation knows of the three views it offers for editing data. The TextView offers the raw Xml, tags and all. The GridView shows the schema in a table-like display. This view's advantage is that it can fit a larger document into the editable screen. It takes advantage of Xml's well-formedness and shows it in nested boxes with a drop-down-like clickable format. Finally, the Xml Schema view offers the WYSIWYG graphical view that enables the visual editing of schemas in a friendly display.

I say the three personalities of XmlSpy©, because each view allows one to validate the Xml Schema, and the results are not always identical. Indeed, most of the time the tool will show the same validation results in all three views. If there is an obvious error, or a simple one, then the same message is thrown regardless of the view. But on occasion, the three views differ on their results. I've gotten a few questions over the years about what should be done when faced with different responses of this tool based on the view.

A query into Altova, the company that makes it, regarding this behavior came back with some interest results. They indicated that the validation code that is performed in the three views is different, although they did not say exactly how they were different. I then asked "which view is correct" when presented with the inconsistent results. They stated that the TextView was the most thorough, and therefore the most authoritative, validation path. We were advised to go with the TextView results and ignore the others.

I've been using XmlSpy for many years now and have come to the conclusion that the issue does not stop here. What I have found is that you should strive for all three views to agree on validation results. If even one view returns differing results on validation, then there is usually some issue to be resolved. It could be in the Xml Schema, it could be in the memory management of the tool, and it could be gremlins in the gears. Every time I have had differing results, I have either found some issue to be resolved with the schema, ended up restarting the tool and trying again, or reporting a bug. In the first case, it required some work on my part to resolve; however, ultimately, all three views have agreed on validation before I was finished. So I recommend you make sure all three personalities agree with each other.

3:01:03 PM    comment []

Interoperability is a goal with which few people would disagree. In fact, it is always on the mind of those trying to integrate systems and use standards to help. However, it is a term that, while we can easily agreed upon as a goal, its exact meaning can have variations. Assumptions or corollaries about the true meaning of interoperability can affect the steps we take to achieve it.

So what does interoperability mean? Wikipedia defines interoperability as "the ability of products, systems, or business processes to work together to accomplish a common task". This strikes me as a reasonable definition at a high level. We can also define it in more detail as it applies to connecting systems together with data standards. In my view, we can break this down into 3 major categories or types, namely syntactic, transactional, and semantic.

Syntactic interoperability is the ability of trading partners' systems to understand each other outside any subject domain. Things such as web services SOAP as an enveloping technology, HTTP as a transport medium, and Xml as a structure for containing data of any kind (and Xml Schema as an arbiter of that structure) are ways in which implementers can agree on syntax.

Transactional, or scenario, interoperability is an agreement to a certain setting for data transfer. Here we can model a use case that indicates a request-response pair of interactions that are expected on both ends. If we agree that "I'll send you a benefits enrollment for a subscriber" and that I'll expect a response indicating "the success of failure of that enrollment in my system" then we've agreed upon a scenario for passing data.

Semantic interoperability is the ability to agree on the meaning of the data itself. This can simply be getting your PersonName to mean the same thing as my PersonName. And even here, there are multiple types. First, we need to literally define what a PersonName is so that we can agree. Second, we need to work on common usage. For example, I may key my system on last names of persons, whereas you may only want the formatted version of a name so as to display it in a web page presentation.

While there are entire tomes written on this word, I wanted to at least blog on the 3 aspects of it that relate to data integration. Here is a brief round up of some items on this topic.

• Achieve semantic interoperability in a SOA
• Chris Ferris' blog, a frequently referenced guru on interoperability issue in web services. Chris is on the Senior Technical Staff at IBM.
• Simon Guest's blog postings on web services interoperability. Simon is a Microsoft Architecture Strategy Product Manager.
• Web Services Interoperability Consortium web site. WS-I is dedicated to providing interoperable web services via profiles of infrastructure technology standards.
• WebServices.org blog site, with several bloggers contributing.
• Web Services: A Realization of SOA

12:55:04 PM    comment []