Why XTM 2.0 is different from 1.0

<< 2006-12-16 19:17 >>

Many people have asked what the changes between versions 1.0 and 2.0 of XTM are, and what the rationales for the various changes are. The actual list of differences can be found in the standard itself, but the standard says nothing about why they were made, and so I thought I would give a quick overview of that here.

A bit of background may be useful. XTM 1.0 had a number of design goals specified up front, but there was no clear decision on what kind of format XTM 1.0 was supposed to be. For XTM 2.0 we took the position that the purpose of XTM 2.0 is to allow topic maps to be transferred from one place to another. Period. This meant that functionality to make it easier for people to work with topic maps stored in files (without using Topic Maps software) was not a priority at all, and some of the changes follow from this principle.

XLink and XML Base

XTM 1.0 used both XLink and XML Base, but XTM 2.0 uses neither. In both cases the reason is the same: using these technologies made the specification more complex, and using them achieved essentially nothing.

XML Base, for example, allowed one to specify a base URI for the XTM document that was different from the URI from which the document was retrieved. This allowed the use of relative URIs for URIs based on the base URI inside the XTM document, which makes the document shorter and simpler. However, it's rare for XTM documents to have so many similar URIs that this is helpful, and the savings are in any case small, given how verbose XTM is.

The downside of having XML Base is that the specification has to explain what it means to use this attribute, and one gets into interpretation issues regarding what URI IDs should resolve to, etc. Cutting this functionality really loses nothing of value, and at the same time reduces complexity.

The same applies to XLink, since XLink doesn't really provide any functionality that XTM has any use for. All XTM needs is the ability to put URIs into XTM documents, and a simple href attribute is sufficient for the purpose. And just as with XML Base XLink presents challenges such as what do with the required (but superfluous in XTM) xlink:type attribute, etc. Again, removing XLink makes the specification simpler, and in this case there is no loss of functionality at all.

The name changes

A lot of elements have simply changed names in the two versions, and for the most part the reasons are simple. The complete list is below.

• The parameters element (used for scope on variant names in XTM 1.0) is called scope in 2.0. In XTM 1.0 variant names actually don't have scope, and so the "parameters" really provide a processing context in which the name applies. However, in TMDM this has become scope, and so the name had to change.
• The roleSpec element (used for type on association roles in XTM 1.0) is called type in 2.0. The reason is that in 1.0 roles are called members, and role types are called roles. TMDM changed this, and so the names had to change as well.
• The member element (used for roles in XTM 1.0) has changed to role in XTM 2.0, for the same reason.
• The baseName element is called simply name in XTM 2.0, for reasons of simplicity and brevity, mainly.
• Similarly, the baseNameString element changed its name to value for reasons I should think obvious.

The removals

We took out a few things in XTM 2.0:

• In XTM 1.0 all elements could have an ID attribute, which meant that if you wanted to you could refer to a specific topicRef element in a file, for example. However, only the IDs on elements which represented things that could be reified served any function. So when we came up with a better way to do reification (see below) we dropped the IDs entirely (except on topic elements).
• In XTM 1.0 the subjectIdentity and variantName elements were used as wrappers or containers, but the syntax would have worked just fine without them. In the interest of simplicity we removed both.
• In XTM 1.0 you could not just merge in another XTM file, but you could also add scope to all characteristics in that file when you merged it in. This was, in theory, supposed to allow people to track where statements in a topic map came from. In practice, however, it was hardly ever used, and it doesn't really do this tracking as faithfully as people think. Since we thought that this sort of "transformation operation" did not belong in an interchange syntax, we removed it. (We would have removed mergeMap, too, since this is just a syntactic convenience, but pressure from users was too strong to allow this.)

The structural changes

A number of structural changes were made in XTM 2.0, mostly reflecting how the abstract model of Topic Maps was tightened by the introduction of TMDM. Some also reflect how we learned more about the role and use of XTM in the five years from the completion of XTM 1.0 in 2001.

• In XTM 1.0 member elements could specify any number of role players (including zero). However, in TMDM, each role must have exactly one player, so in XTM 2.0 we changed the syntax accordingly.
• In XTM 2.0 the instanceOf element has been broken into two elements. instanceOf remains as the mechanism for specifying the type(s) of topics, but type was introduced for all other type specifications. This was done because the two relationships are actually different (and represented differently in TMDM), and we thought this would be clearer for users.
• In XTM 1.0 variant names could be nested, which led many to think that the name structure of topics was actually a hierarchy. In reality, the only thing the nesting did was to inherit scopes, thus allowing a more compact specification of variant names. We viewed this as a confusing syntactic convenience, and have never seen it used in practice, and so decided to remove it, which simplified the syntax without losing any functionality.
• In XTM 1.0 occurrences, associations, and roles were not required to have a specified type. We really could not see any reason to allow these to be typeless, and requiring a type in both the model and the syntax makes Topic Maps a simpler standard. Actually using this "feature" of XTM 1.0 is considered bad practice, in any case. Also, anyone wanting untyped occurrences (for example) can still do it by defining their own "untyped" type, so there is no real loss of functionality there.

Extensions

A very few extensions have also been made in version 2.0:

• The version attribute was added to the topicMap element so that we would be able to make minor updates in the future. Processors should then be able to tell what version of XTM they were receiving by inspecting the version attribute. Since it's on the document element they can do this before they start reading the topic map.
• Support for typed data was added in XTM 2.0 in response to user requests for this functionality. This includes support for embedded markup. In the syntax this only shows up in the form of the datatype attribute on the resourceData element.
• Typed names is now supported. This was added for political reasons, but it was added because there was a real need for this functionality. Users were already typing names via scope, which was not very pretty, and allowing names to be typed avoided ugly modelling kluges.
• The reifier attribute has been added on all elements which represent something that can be reified. This isn't really an extension, just a change in how reification is expressed. In XTM 2.0 it is expressed by means of a reference from the construct being reified to the topic that reifies it. (In XTM 1.0 it was done by means of a subject identifier pointing to the reified construct, which wasn't really very pretty.)

Similar posts

Comments

Add a comment