The ability to create a subset schema is a perenial request I get from clients in the data integration space. Using standards developed within their industry consortia, they need to restrict the base schemas into ones that reflect the needs of their particular business scenarios. A subset schema (or "lite BOD" in the OAGIS lingo) is a schema that adds addition restrictions onto an existing schema. For example, removing optional elements that are not implemented can be done by deleting them from the schema. The resulting schema (called a subset) is still conformant to the original data model. And an xml instance of that subset schema will validate against the original data model schema.

Restrictions can include:

• removal of optional elements
• making optional elements required
• removing enumerated values from lists
• making a choice of elements into a sequence of one of the choices

It cannot include (because these are additions or extensions and not restrictions):

• making required elements optional
• adding additional enumeration values to a list

A tool called GEFEG can do this function. I wish there were others too. I've often wanted to create one myself using xforms and Xslt. But have never had enough time or someone committed help me do it. Anyone care to lend a hand and help me do this?

Data integration would really be enabled if we had this subsetting issue resolved.

8:25:55 AM    comment []

Interesting thread on the XML-DEV list about Xml as a long term archival storage medium. Years ago I was trained as an archivist and so this topic was certainly of interest. The thread begins with a query as to what happens in 2027 with respect to Xml data. In this day, Xml is said to have disappeared from the scene (imagine the movie promo guy saying "...in a world where Xml has vanished...").
All that is needed to read and manage this Xml data is the ability to understand ascii or unicode. And in fact, that is the case.

I did some coding for the state of north carolina archives and records division prototyping and conversion of governor's records into Xml as a long term storage medium. So in archival terms (meaning 2127 instead of 2027) all that would be needed to read this material is a program that understands unicode.

Of course there is a physical issue too. One needs to be able to read the disk/harddrive/tape or other physical format in order to read the data as well.

4:28:46 PM    comment []

• I checked the drivers on my drives and found no problem (I don't even use my DVD drive so it isn't related to its frequent use)
  
• Did a memory check using the Memory Diagnostic Tool (see link below in solutions page) and found no error.
  
• an old fashioned virus scan showed nothing (even though I know it isn't a virus - but hey that is always the first response for a problem, right?)
• Checked the hotfixes to see if they installed correctly and there was no problem there.
• Even used the Windows Driver Verifier utility, a first for me
  

10:11:40 AM    comment []

I've come across a few clients now with some internal debate as to whether SOA is a good idea. Sometimes of course it isn't. But when part of an organization buys into the value proposition and another doesn't, there can be serious conflict. A couple clients I've had have been in the throws of this debate but the interesting part was that the management and business analysts had bought into idea, but the IT department was dead set against it.

As it turns out, I've noticed 2 common reasons why IT departments resist adopting SOA architecture. The first reason is, they have deadlines. This is where the IT department understands the value proposition and may even be enthusiastic about its possibilities, but they are either understaffed or overcommitted to current, immediate concerns. In short, its hard to think about a better house when the one you have is on fire. The only progress that can be made here is baby steps at best.

The second reason I've found that IT departments resist SOA is that they see it as "just another rearchitecting". These folks are long timers and have heard many pitches about new technologies that will make their lives better. They are experienced and jaded enough to view SOA as just another one of these fads. What is even more interesting is that sometimes they are using SOA-like thinking but are just not calling it SOA. For example, focusing on discrete services they offer to clients. Enforcing good best practices (governance) of those service architectures. Using standardized data models. All of these are good SOA features. Because SOA did not invent these features, some people use them but don't call it SOA.

In my book, I often avoid the term SOA when talking to clients, because it can bring up assumptions or opinions on the term rather than get to what it means in terms of practices. So I don't care if you call it SOA, if it works for your use case, just use it.

9:42:00 AM    comment []

Been reading alot recently about HR-XML Resumes and the hResume microformat especially on the HR-XML blog (see references). I was interested in what the differences between them were and what use cases might be most beneficial to each. As it turns out, the differences were minimal in terms of semantics, at least for the most often used resume fields of data.

I then got a wild hair and created an XSLT to transform an HR-XML Resume into an html document with the hResume microformat embedded in it. (The best way to learn something is to use it for real, right?) It really wasn't hard at all. First, I went to the http://hresume.weblogswork.com/hresumecreator/ tool to create a resume for myself using hResume. I used it as a model. I made no attempt to "pretty it up" as that was not the point. I took the formatting that they used without change. Then I took an HR-XML resume of myself and began to do the transform.

Here is the result of the transform.

• PaulKiel.xml (HR-XML resume)
• hr-xmlresume2hresume.xslt
• PaulKielResume.html (resulting hResume microformatted html)
  

References:
Tapping into Competencies with hResume and a “Wikipedia of Skills”
http://www.hr-xml.org/blog/?p=161

hResumes and HR-XML’s Resume
http://www.hr-xml.org/blog/?p=158

hResume Microformat
http://microformats.org/wiki/hresume

Roger Costello on hResumes and “Unanticipated Mashups”
http://www.hr-xml.org/blog/?p=156

3:13:59 PM    comment []

• PersonName - UML class diagram
• PersonName - Xml Schema
• PersonName - XMI file
• PersonName - C# class
• PersonName - Java class
• PersonName - Access database file
  

12:34:45 PM    comment []

I had an interesting problem to solve recently regarding Xml Schemas, XSLT and namespaces. The task was to use XSLT to create Xml Schema dynamically. This was something I had done before and figured I would pull upon previous work to give me a head start. The interesting part was the requirements around creating namespaces. Dynamically created namespaces can be tricky enough, especially if you are not yet using XSLT 2.0 as I was. The added feature was that I needed to use pre-defined namespace prefixes on those dynamically generated namespaces.

In short, I was tasked with generating namespaces in a resulting Xml Schema, based on data dynamically created at processing time, and with namespace prefixes predefined.

The tempation is to try something like this:

<xsl:attribute name="xmlns"><xsl:value-of select="$xmlns"/>xsl:attribute>

But that doesn't work. The solution is to create a dummy attribute and copy it to the result via the namespace axis and local-name.

In the scenario here, I want to create 3 namespaces, one for the default and target, a second for "common" components that are to be imported, and a third for "custom" components that are used for extensions.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://xmlns.myexample.com/v3" targetNamespace="http://xmlns.myexample.com/v3" xmlns:common="http://xmlns.myexample.com/common/v3" xmlns:custom="http://xmlns.myexample.com/custom/v3"

1:01:37 PM    comment []

I'll preface this by saying that I love the new features in XSLT 2.0. The very first features that I used were ones that took care of some problems around grouping of nodes and finding unique ones. The xsl:for-each-group is a life saver. Previously, I'd used tool extensions such as Saxon's saxon:distinct() function to solve the problem. However, depending on the client, I may not have had the choice to use 2.0 or extensions. So I was stuck with trying to find out how to group nodes or find unique nodes using XLST 1.0 features and without proprietary extensions.

Some solutions have been documented, most notably Jeni Tennison who describes the Muenchian Method to grouping nodes. And this is probably the best one.

The problem is that the Muenchian Method requires the use of xsl keys. Some processors (and Jeni notes James Clark's XT is one) don't implement keys. I am a big fan of XT for certain applications and continue to use it on occasion. So I wanted to highligh how I've done grouping, iteration, and uniqueness without keys or extensions and using XSLT 1.0 techniques.

Assumptions:

• I assume the same scenario as in Jeni's example. Records in a database that contain contacts that need to be sorted. Surnames need to be displayed only once (uniqueness) and matching all forenames (iteration).
• I am using XSLT 1.0 without any extensions
• I cannot use keys.
• I need to iterate through a unique list of nodes (there are likely duplicate values within nodes)
• There are an unknown number of nodes to iterate through.

While this example is very simple, and could be done with the preceeding or following axes, a complex xml may cause the XPath to get too confusing to track. This method keeps the XPath simple.

The whole story can be found here.

4:55:07 PM    comment []

For the last few months, I've been delving deep into the world of ebXML Core Components Technical Specification (CCTS) and the Xml Naming and Design Rules (NDR). It is a world that is becoming more and more the basis of standards development frameworks. Organizations such as OAGi have been at the forefront of its development. CIDX, HR-XML, ACORD, AIAG, UBL, and others have been involved in, are working on, or are at least examining core components as the basis for interoperability across domain standards.

As with any major development, its complexity is its greatest asset and its greatest weakness. On the latter, I was often one who scratched his head trying to understand the acronym soup that is CCTS. I frequently felt that while the theory was good, the gap in education and awareness was the biggest hindrance towards its adoption. Now that I have been deep into the specification, I feel much more enlightened. And I feel like there are in the pipeline some really interesting implementations that will help usher the CCTS into a new phase as the basis for interoperability.

The very real problem with interop across domains is that either one side has to give up its well-developed and well-designed components in favor of another OR both sides need to split the difference and agree to a common data model that neither had in full. For industries that have an established installation base, the cost of doing this is significant. So one first needs to develop the business need for making change. Then, once the case is made on the business level, then the work of finding a common framework begins. Certainly the convergence of groups such as the ones I've listed makes things easier and it seems fairly clear where things are headed. This was not the case until relatively recently I should add. Case in point is this cross industry core components workshop held this past summer.

So watch out for the emerging support for CCTS in the future. I'd love to spend some time and work on its usability. Doing some educational pieces or develop some training modules for this to make it easier to comprehend and get started. By comparison, I look back at the great value of the educational efforts of Roger Costello in advancing the complex spec that is Xml Schema. Would love to work on the same for core components.

5:50:43 PM    comment []

Definition:

"dot oh" = version controlled terminology used as marketing speak to describe a concept

The concept may be a new one or it may simply be new to the marketing department. Most importantly, advocates want readers to believe it is new. The underlying concepts can be very meaningful, especially when one tries to compare trends (as in SOA versus Web 2.0). I just cringe at the shrink wrapped packaging of fuzzily defined terms. So let's talk about the meat on the bones. Here is the run down.

SOA 1.0 - client/server service oriented architecture. This is what we know today as SOA including soap/web services.

SOA 2.0 - event driven service oriented architecture. Defined as "a software architecture that defines how systems can be engineered and designed to sense and respond to events."

blogs.zdnet.com/service-oriented/

infoworld.com/article/06/05/17/

javaworld

Web 2.0 - Collaborative, fast development of applications. RSS/Atom, mashups, wikis and the like. Often uses existing technology in a new way to add value.

Web 3.0 - Semantic web. RDF and related semantically based applications.

http://blogs.zdnet.com/service-oriented/?p=753

http://www.hr-xml.org/blog/?p=98

I think these terms really have meaning when it comes to comparing trends. Comparing SOA (1.0) versus Web 2.0 is an interesting one. The idea behind these indicates two different views of how applications are to be developed. Take data integration (something I know a bit about). The traditional route of thinking is to create a data model of a business document, express it in Xml Schema, and ship it to my trading partner via services as SOAP (or message que or ...). This reflects a certain architecture and modeling that is not trivial. In a web 2.0 world, you could have a data integration in simpler terms. Use Xml and share it with trading partners via simple https or even syndicate it via RSS. The former is basically architected and the latter is mashed together. This reflects an interesting debate about how to develop apps and integrate systems. Each has their own strengths and I think will both have their niches, so I think it is a false choice.

Comparing Web 2.0 with Web 3.0 is also an interesting one. The web2.0 is intended to be quick, easy, leveraging existing apps, and collaborative in nature. The idea of a semantically based web (3.0 here) is basically the opposite of this. Many will disagree with me here, but creating a semantic web is very difficult and involved alot of analysis which is the antithesis of the quick mashup. Entire companies do nothing but mine business data in a semantic web based fashion. So here again each of these concept has their own niche.

As a side bar, I am an old librarian/archivist and so am sympathetic to semantic web technologies. I looked at RDF a long time ago and have always wanted to justify using it in my work, but never had the opportunity. I even had a thought to use it at HR-XML. But I always kept getting caught between what was the ideal thing to do and what was the reality of current demands.

9:13:11 AM    comment []

Once again Joe McKendrick is spot on. The jist of this posting is that we can get past the buzzword effect and solve real world business problems. Whether we call it proper SOA or not doesn't matter.

http://blogs.zdnet.com/service-oriented/?p=746

8:44:47 AM    comment []

After all the xml and xml schema tools I have tried over the years, I often come back to wanting to test each one to see what Xml Schema features it supports and which it doesn't. In order to test these, I need a test suite of features in the form of a sample xml schema and xml instance. I have tons of schemas accumulated from many different domains and sources. However, I wanted just a simple, single schema that packed in one of all the schema features that could fit in it. Searching the web did produce some test suites, such as the Test Collection and the Test Suite from the W3C. These are good, but they are in many files and are a bit much for my simple tool test use case. I just wanted a real simple, single example file.

So here is an early version of this simple Xml Schema test file. I have a more detailed version of this with even more schema features as well as an xml instance conforming to it.

A few other links:

• This is related to the Xml Schema Profiles postings I've done. Entry 1 usage profile and entry 2 code generation.
• w3.org/XML/2004/xml-schema-test-suite
• lists.xml.org/archives/xml-dev/

UPDATE:

You can find the simple XSD here.

You can find the simple XML Instance here.

5:37:21 PM    comment []

Some recent debate on SOA has come across the blogosphere with 2 theories:

1) SOA is a technical solution (not a business one) and the term has been hijacked by marketing hype.

2) SOA is nothing different than what has been done with the web from the beginning.

Some links:

blogs.zdnet.com/service-oriented/

redmonk.com/

Each of these perspectives have their underlying truths. I think some folks may be thinking too hard here. The fundamental problem for IT always starts with a business problem. (or always should start with one.) So in that sense I disagree with the first theory. If my mousetrap is working fine, why would I want to risk anything by changing it? Even if the new spiffy SOA architecture will save the world? A business problem at hand is the beginning. When the business folks say "we have a problem that needs fixing" or "we have an idea for a new service for our customers" then we get to IT. The technologists can architect the best way to solve the business problem using technology.

Now perhaps SOA has suffered from hype and been over marketed as a solution for everything. This part of the first theory I agree with. But it doesn't negate the value underneath it. It simply reflects the fact that SOA is a very loosely defined term. It can mean many things in many contexts. In the end we start with business problems, and apply architecture to best solve them. If we do this in a loosely coupled manner, we get SOA. Sound familiar?

Technology is the means to a business ends and not an end in itself. Once a problem exists, then there is an opportunity perhaps not only to solve an immediate problem, but to plan for the future. Service orientation can occur during these architecting spaces in the development cycle.

Regarding the second theory: yes, the web itself is a great service oriented solution. eBay, Amazon, etc all provide services in a decentralized and decoupled way. SOA brings this same thinking inside an enterprise. I recently spent some time working on some data integration issues for a large company that had many acquisitions. With all the growth and subsidiaries, I don't know how they would even try to offer stovepipe solutions. Decoupled and service oriented is the only way possible to get anything done in the short term. They may or may not call it SOA, but it fits the bill in my book.

1:37:03 PM    comment []

In my original posting, I did some looking around at publically available listings of support for Xml Schema features among code generation tools. In my research as a follow up, I realized that if I did a bit more work that it would make for a better article than a simple blog entry. Xml.com bought it and here is the full article:

xml.com/pub/a/2006/09/20/profiling-xml-schema

4:39:31 PM    comment []

One of the key responsibilities I had at HR-XML was figuring out how our standard schemas would work within existing tools. As time went by, IDEs became more and more compliant to the spec. Then there was growing interest regarding code generators. Specifically, the idea is to generate stub code (or more) from the xml schema that would give you a head start on processing the xml that is valid against it. I'd done some testing and got some feedback on other tools. (An interesting list of data binding tools is here.)

I wanted to revisit this topic in the context of Xml Schema Profiling. Creating a profile of Xml Schema at one point was controversial, witness the former Xml Schema Profile work group activity at WS-I. This ended up being addressed in the W3C Xml Databinding activity now underway.

But we all know that things are rarely 100%. What I'd like to do is examine some of the documentation around what features of Xml Schema are routinely not supported in tools. Is there a sort of Xml Schema Profile consensus? Here I touch base with some of the more common ones:

Xsd.exe, Castor, XMLBeans, JAXB, CodeXS, XSDObjectGen, Systinet, webMethods, Dingo, and Xmlspy.

The whole story is found here.

10:54:41 AM    comment []

Been checking out the new Xsd.exe tool that ships in VS.net 2005. While I only have the beta installed, it has already shown to be valuable. I've been checking this code generation tool to see if it has been improved. The last version I looked at had numerous problems and really was not worth the effort. While at HR-XML, we got so many complaints about this older version that we recommended folks find an alternative such as XsdObjectGen or CodeXS. Neither of these latter tools had the problems of the original Xsd.exe. I even had some long emails on schema support in tools with the CodeXS people. I found them to be smart folks.

However in the new version of the Xsd.exe tool has indeed improved. The classes actually compile (no small feat given earlier experience) and there is better support for Xml Schema structures. I am impressed with it thus far.

This is not to say that Xsd.exe supports the entire Xml Schema spec (see profile of serialization class). Few tools do. Profiling Xml Schema is a subject I've blogged about in the past and am working on an update. Stay tuned for that.

5:19:34 PM    comment []

Been hearing some wranglings over W3C and Consortium standards processes (see links at bottom). While I have not worked in the W3C (not had a company willing to pay for participation), I have worked with a Consortium standards process, namly HR-XML. It seems there are several issues:

1. Openness. This is a common complaint of folks outside the Consortium process. And there is validity to it. The problem is that one needs to pay the electric bills too. At HR-XML, we were a globally scoped organization with an extremely small full time staff. We kept barriers as low as possible (such as having individual memberships), but ultimately there are costs that need covering. I'd be more concerned about "how" the Consortium spends its money rather than whether pay-to-play is valid to begin with.
   
2. Diminishing returns. A general pattern for acceptance of standards is shooting for a good "1.1". The first version, 1.0, is the first thing that many people take note of, except the few that worked on it. Getting implementation feedback on 1.0 makes a real good push for a quality 1.1 version. However after that, the law of diminishing returns comes in. The number of problems you solve with 2.0 is often less than the number you solve with the 1.1, and so on. The great base specs, XML, HTML, CSS, XSLT, etc solved many problems. But getting folks excited about working on CSS 5.0 or some such can be hard and not as compelling.
   
3. Reinventing itself. Each year, Consortia need to reinvent themselves to justify to their members why they still need to exist. In essense, one has to constantly re-justify one's existance. So there is a tension between sticking to one's bread and butter and moving on to new ventures. Stray too far from your bread and butter and your membership withers. Don't venture into new territory and members wonder why they fork out fees. Here is a great article on associations .

   "Operating a professional or trade association has a number of sisyphusian characteristics. At each step of the organization's evolution, the core staff must deliver more novelty and interesting experiences in order to convey additional value. Each year, the cycle begins anew. The largest risk in the association business is that the enterprise will lose its relevance while navigating the hamster wheel of ongoing operations. The penalty for failure is mediocrity. The reward for success is rarely excellence. It's more like 'a little bit better than mediocrity'. It's a very tough grind."

4. Decision by committee. This is used as a derogatory comment, but studies generally find that decisions made by a group are better than those done by individuals. It's the least bad mechanism.
   
   
5. Democracy or marketshare based influence. Another complaint is that large multinationals disproportionately influence the results. The assumption is that there should be a true democracy. Well, what kind of standards would actually get implemented if a one-person consulting firm has the same say as IBM or Microsoft? Yes a true democracy is an ideal we hope to achieve, but there is a marketplace reality. These larger companies get disproportionate influence because the end result will fail without them. This is leverage. Lack of big multinational support does not mean standards can't succeed, but it would need to be really compelling to overcome this. I'm not saying it "should" be this way or that its fair in any way. It simply is a fact and needs to be shown in the light. A successful Consortium must balance an ideal of democracy with the reality of market share based influence.

It was Churchill that said Democracy is the worst form of government, except for all those other forms ...

Here are links to the controversy and responses to it:

blogs.msdn.com/xmlteam

25hoursaday.com/weblog

docuverse.com/blog/

http://meyerweb.com/eric/thoughts/2006/08/14/angry-indeed/

5:29:09 PM    comment []

I frequently get requests for good sites for people to get up to speed on various Xml related technologies. In terms of usability, there are some stand outs. Because I learn best with examples (annotated ones are even better), the Xml Schema tutorial at www.xfront.com is amazing. Roger Costello developed it. He helps bring a complex topic into the light. This will take you from novice to expert if you consume all the information.

A good "first place" to go is the very simple but effective W3Schools. www.w3schools.com. It is for the newbie and doesn't pontificate on any topic. Straight forward and easy to consume.

And by far the best place I have found for ongoing reference is Zvon.org. www.zvon.org This site, while not exactly simple to use, contains a wealth of information and references on all kinds of Xml related technologies. Lots of examples, downloadable tutorials, and quick reference sheets. Xml, Xslt, XPath, Xml Namespaces, CSS, Schematron - you name it and it's there. Whenever I get stuck and can't remember a feature I haven't used in a while, I refer to this site.

4:42:45 PM    comment []

There has been quite alot of debate around "Web 2.0 versus SOA". I've included a couple detailed links below. Personally I think these approaches serve different functions and are complimentary. Web 2.0's benefits "tend" to be outside the firewall. RSS, blogs, wikis, and mashups are great for connecting folks together collaboratively, quickly and simply. SOA, in the other hand, has benefits around how software and services are engineered. Yes, they result in connections outside the firewall, but they are big drivers in how software is developed to support services inside the firewall.

There is a great 2-part blog on this debate by Joe McKendrick (with lots of internal links to other material in this debate):

Web 2.0 or SOA? Web 2.0 and SOA? Let the Debate Begin! - Part 1

Web 2.0 or SOA? Web 2.0 and SOA? Let the Debate Begin! - Part 2

12:53:48 PM    comment []

I have often gotten questions regarding the use of default namespaces in Xslt. It is really an XPath issue, but it becomes an issue as folks progress from using Xml data documents (which handles default namespaces nicely) to doing transforms. They want to minimize the impact of namespaces, and so use the same logic in the Xslt as in their data documents. However logical the thinking is, a common gotcha is to try to use a default namespace in XPath statements in an Xslt template.

It is a real gotcha that trips up folks getting started with transforms. Instead of using a namspace prefix for every node of every XPath statement, they think that a default namespace could make their lives easier. It is a logical conclusion. Given this Xml snip:

<BackgroundSearchPackage xmlns="http://ns.hr-xml.org">

<Screenings>this is the screenings element contentScreenings>

<AdditionalItems>this is the additional items element contentAdditionalItems>

BackgroundSearchPackage>

Stylesheet writers think they can get the value of the child elements by using the XPath:

<xsl:value-of select="BackgroundSearchPackage/ Screenings/ AdditionalItems"/>

This of course does not work because it does not have a namespace reference. When they add in a namespace prefix, it looks like this:

<xsl:value-of select="hrxml:BackgroundSearchPackage/ hrxml:Screenings/ hrxml:AdditionalItems"/>

However this seems awkward and unnecessarily repetitive. (An alternative would be an even more awkward syntax using "local-name()".) The logical conclusion is to define a default namespace in the Xslt and that would solve the repetitive prefix in all XPaths. While quite logical, this in fact does not work.

Indeed, Xslt 1.0 writers need to get used to the prefixes in their XPaths, because they are necessary for hitting the node correctly. The 2.0 of Xslt addresses this common gotcha.

6:06:48 PM    comment []

This annotated version of the Xml spec is something that I refer back to occasionally. Sometimes there is nothing so good as to go back to the source. It answers questions like "why did they do that" and such.

http://www.xml.com/axml/testaxml.htm

9:44:49 PM    comment []

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 []