RE: Data Interoperability ... Why do some XML vocabularies specifymeanin

["Cox, Bruce" <Bruce.Cox@USPTO.GOV>]

Roger, you first speak of "purpose" as if you were talking about what the tags mean, then you proceed to talk about the "prime app" for a schema, where "purpose" has now become something about the syntax.  A validator addresses syntax, not meaning (well, that's what I believe).  If a vocabulary is ascribed a primary purpose, I should think that would be about the business or social context and the goals of the creator of the vocabulary, not the syntax.

When we were creating WIPO Standard ST.36, we found that many different industrial property offices (IPO's) could ascribe a sufficiently similar meaning to each of the elements in the vocabulary to achieve the desired degree of interoperability.  I attribute this early blush of success to the fact that the DTD's were based largely on other WIPO standards related to various industrial property treaties that had existed for many decades.  In other words, someone else had already done the heavy lifting of building a common understanding of the business vocabulary.  We added the syntax.  We also specified which version of XML, XSLT, CALS, etc., that we'd use, in order to ensure the necessary level of syntactical interoperability.

Well, as it turned out, we were a bit naïve fifteen years ago.  A few years after ST.36 was ultimately published, we developed an "interoperability matrix" in which we examined the meaning assigned to, and internal processing associated with, certain key elements in the vocabulary, across some six different IPO's.  The result was a list of business rules that would require harmonization among IPO's in order to be able to process exchanged documents successfully, even if they did all conform to ST.36.  What had appeared to be "sufficiently similar" was often not sufficient for the intended purpose.

As others have pointed out in this thread, that might not matter in some cases, and indeed, it's the very foundation of certain XML-based use cases.  In other circumstances, it's a show-stopper.

At the moment, we're modernizing the editorial processes for the Manual of Patent Examining Procedure and the Trademark Manual of Examining Procedure.  They've been maintained independently for about sixty years.  It was a great relief to discover that we can use one XML Schema and one set of style sheets for both documents, nearly identical in the abstract, even if they diverge in most of the rules that they document.  The editorial workflows are also very similar.  

In this case, we're using the process of developing the Schema and style sheets to introduce the editorial staffs to each other and discussing their needs jointly in an effort to reduce the work needed to create the infrastructure system supporting them.  The level of interoperability we're after is all about the documents (rule books) and their maintenance, and not about the business (patents vs. trademarks).  

This suggests that there are at least three areas to consider when the goal is interoperability: business semantics, standardized syntax, and supporting infrastructure.  Adjust the level of conformity needed in each to achieve the desired result.

Bruce B Cox
Director, Policy and Standards Division
USPTO/OCIO/OPG
571-272-9004

These are my personal views, not those of the USPTO.

-----Original Message-----
From: Costello, Roger L. [mailto:costello@mitre.org] 
Sent: Friday, August 20, 2010 7:57 AM
To: xml-dev@lists.xml.org
Subject: RE: Data Interoperability ... Why do some XML vocabularies specify meaning + behavior whereas others specify only meaning?

Hi Folks,

Thanks to Michael Kay, Ken Holman, and David Carlisle for their excellent inputs. 

Long ago someone on the xml-dev list said:

   An XML vocabulary is created for a purpose;
   otherwise, what's the point.

The purpose may be to do something, take an action, make a decision, etc. Even an XML vocabulary created to be purely informational (John likes cycling) has a purpose such as: make the information accessible. 

An XML vocabulary may be used for different purposes, but there is always a prime purpose. For instance, XML Schema may be used for different purposes but its prime purpose is validation. XSLT may be used for different purposes but its prime purpose is transformation.

I will use the term "Prime App" to mean an application that implements an XML vocabulary's prime purpose. Thus, an XML Schema validator is the Prime App for the XML Schema vocabulary. An XSLT processor is the Prime App for the XSLT vocabulary.

As a corollary to the above quote, I propose this:

   An XML vocabulary must have data interoperability;
   otherwise, what's the point.

I have often heard it said, "To achieve data interoperability each application must interpret/understand the XML vocabulary in the same way."

What better way to ensure the same interpretation/understanding than to use the same application!

I am led to these 3 conclusions:

1. When you create an XML vocabulary, specify the behavior of the XML vocabulary. Specify conformance requirements. Create a conforming Prime App. Create a test suite. Everyone use the Prime App.

2. Data interoperability is not achieved through shared understanding of the XML vocabulary. Data interoperability is achieved through shared usage of the Prime App.

3. Creating an XML vocabulary without specifying its behavior is a bad idea. It is a recipe for delayed data interoperability at best, failed data interoperability at worst. For example, the XHTML vocabulary does not specify behavior. Each browser vendor had their own idea of the proper behavior of the XHTML vocabulary. The result was years of non-interoperability. It's taken over 10 years for the vendors to finally converge on a common browser behavior. Browsers could have had (theoretically) common behavior 10 years ago had the XHTML specification specified behavior of the Prime App (browser) along with conformance and test suites.

Comments?

/Roger