Managing multiple vocabularies across a global enterprise

Organizations share vocabularies across disparate user groups and data to maximize the value of their investment in XML, and, without question, those XML vocabularies need to change as the businesses evolve and expand. Managing change to DTDs and schemas is difficult enough with a small group of co-located users working on the same content types. What happens when you have hundreds of XML consumers spread across the globe and they have completely different requirements, systems, and content? Get a view of the challenges of implementing change management and vocabulary versioning on a very large scale.

Versioning fundamentals

Active XML vocabularies change over time, undergoing the inevitable evolution called versioning. Versioning means adding, deleting, or changing the elements, element content, number of occurrences, attributes, or attribute values described by an XML schema. Approaches to versioning fall into several classes, including compatible, backwards-compatible, forwards-compatible, and strategy-what-strategy. Specific rules enable the successful use of these strategies, such as the "must ignore unknowns" rule, the "must understand models" rule, and prescriptions for the use of version identifiers. Basic versioning concepts and vocabulary will be illustrated using a set-based model for determining compatibility.

This paper has no version: Versioning as a social construct

To declare that something "is" or "has" a "version" is to imply that there is some "original" or true referent for that "version" and that the "version" has some standing in the eyes of some authority. However, whether it be versions of the Bible, versions of documents, or versions of application code, there can be no satisfactory approach to understanding "version" as a purely scalar property. It is necessary to see the concept of "version" for what it is: a social construct that may serve particular needs and may, equally, fail to capture what it is intended to. Understanding this will free us to build information systems that more adequately reflect the mutability of knowledge and its complex relationship with static information.

Axioms of Versioning

The problems of language versioning can be better understood with the help of some formal axioms defining the relations among the extensions and semantics of languages. Such axioms allow us to specify what makes one language extensionally, syntactically, or semantically a subset, superset, or equivalent of another. The difference between syntactic and semantic compatibility makes clear how languages can grow in a forward-compatible way. The key to compatible versioning is to assign new semantics in the new version of a language for syntax that was already accepted in the prior version, but to which the prior version assigned no semantics.

Versions in UBL

There are many aspects of "different versions" when considering the artefacts defined for the OASIS Universal Business Language (UBL). UBL is expected to be widely deployed over a long period of time. How it is specified needs to support deployments in a heterogeneous network of different levels of implementation in different scenarios with different participants. Differences in versions can be seen in three different perspectives of the one specification. This paper describes (1) different versions of the UBL standard defined by the UBL technical committee, (2) different versions of UBL customizations defined by communities of users, and (3) different versions of deployed code lists defined by trading partners using UBL. Some aspects described apply only to UBL because of characteristics of UBL not shared with other vocabularies. This may limit how other vocabularies can take advantage of the approaches being used.

A non-backwards-compatible update: a difficult decision

The U.S. National Library of Medicine (NLM) Journal/Book Tag Sets have been widely adopted by libraries, archives, and commercial publishers. The users are widely distributed, generally unknown to each other, and in many cases unknown to the Tag Set advisory group, owners, and secretariat. The first five revisions to the Tag Sets were backwards compatible, but the most recent is not. The decision to make a non-backwards-compatible revision was not taken lightly. It was made based on several factors, including a decision to favor the needs of future users over the convenience of current users.

Forward compatibility using XML transform-as-needed (XTAN)

It is often desirable to design vocabularies for forward compatibility, that is, to design them in such a way that domain-specific applications that use them can be adapted to changes in them at minimal (and predictable) costs. XTAN is a vocabulary for annotating XML Schemas to indicate how documents that use certain vocabulary extensions can be transformed by an XTAN preprocessor into documents that do not use those features. The transformation may have specific impacts, including losses of fitness for specific uses in specific domains. By using XTAN, systems can provide forward compatibility: a document that uses features not specified in version n of its vocabulary can be transformed automatically (with some impact) into a version n document. XTAN is being developed to meet the needs of the W3C Rule Interchange Format (RIF) Working Group, but the design is general.

Summary and Wrap-Up

There will be a lot of material presented at the Versioning Symposium: prepared presentations, questions and answers following those presentations, and mini-presentations from our Hyde Park Speaker's Corner. This wrap-up will summarize what we have heard, discussed, and learned in the Symposium. Since it will be composed on the fly, the presenter welcomes audience corrections on the points he inevitably will forget or misrepresent.