ISO/IEC JTC 1/SC34 N0277

ISO/IEC JTC 1/SC34

Information Technology --

Document Description and Processing Languages

Title:	Differences between XTM 1.0 and the HyTime-based meta-dtd.
Source:	Michel Biezunski, Steven R. Newcomb
Project:	Topic Map Models
Project editors:	Michel Biezunski, Martin Bryan, Steven R. Newcomb
Status:	Editors' Draft
Action:	For information
Date:	8 December 2001
Summary:
Distribution:	SC34 and Liaisons
Refer to:	220, 238,239, 260
Supercedes:	N270 (part of the answers to the US comments).
Reply to:	Dr. James David Mason (ISO/IEC JTC1/SC34 Chairman) Y-12 National Security Complex Information Technology Services Bldg. 9113 M.S. 8208 Oak Ridge, TN 37831-8208 U.S.A. Telephone: +1 865 574-6973 Facsimile: +1 865 574-1896 E-mailk: mailto:[email protected] http://www.y12.doe.gov/sgml/sc34/sc34oldhome.htm Ms. Sara Hafele, ISO/IEC JTC 1/SC 34 Secretariat American National Standards Institute 25 West 43rd Street New York, NY 10036 Tel: +1 212 642-4937 Fax: +1 212 840-2298 E-mail: [email protected]

The differences between XTM 1.0 and the HyTime-based meta-DTD

Introduction

The ISO/IEC 13250:2000 "Topic Maps" International Standard has two interchange syntaxes, the HyTime-based meta-DTD, and the XTM DTD. The following is a survey of the relationships and differences between these two syntaxes.

Describing the semantics of both syntaxes

One of the purposes of the layered model of Topic Maps Information is to provide a means of describing the semantics of such information, in general, regardless of the representations that may be used to interchange it. The layered model also can be used to show how each different syntax (or other representation) can be used to interchange or store Topic Map Information, and to compare the ways in which each syntax reflects the inherent character of the underlying model of Topic Map Information. In order to rigorously define and constrain the interpretation of each syntax, it is desirable to describe how instances of each syntax can be transformed into instances of the common underlying model, and how instances of the underlying model can be transformed into instances of each syntax.

It is important to recognize that information that has the character of Topic Map Information is ordinarily expressed in many different notations. It is highly desirable to be able to federate all kinds of "finding information", not just the finding information that happens to be expressed in one of only two syntaxes. The underlying layered model of Topic Map Information is applicable to any number of notations, although the ISO 13250 standard uses it only to constrain the interpretation of only two syntaxes -- the syntaxes that it happens to provide. Conformance to the underlying layered model will enable topic map applications to become omnivorous with respect to syntax.

The difference between topic map syntax and topic map information

If we consider a topic map abstractly, apart from the data used to represent it, its structure cannot be the same as any conceivable syntactic structures that could be used to interchange it. Neither HyTime-based nor XTM-based topic map documents are "ready-to-use" by application-specific logic. Before a topic map software application can be expected to perform its application-specific functions, generic parsing -- processing that must be performed in order to understand the topic map that an interchangeable instance of that topic map is designed to represent -- is required to make the topic map "ready-to-use".

From an economic standpoint, there are significant advantages in using a distinct software module that implements this generic processing, commonly called a "topic map engine" or a "topic map parser". (The term "topic map parsing" means "all of the aspects of topic map processing that are required to be done by all topic map software that takes, as input, interchangeable topic maps that conform to any representation used for interchange or storage." The term "topic map processing" is much more generic; it refers to any kind of information processing that involves Topic Map Information, including both topic map parsing (as just defined) and application-specific processing of ready-to-use topic maps.

Differences between the HyTime-based Topic Maps meta-DTD found in ISO 13250:2000 and the XTM 1.0 DTD

Addressing

Addressing in XTM is limited to Uniform Resource Indicators (URI) while addressing in the HyTime-based syntax can be expressed with virtually any kind of notation.

Architectural forms versus fixed DTDs

The HyTime-based meta-DTD is a set of architectural forms, or element type templates, rather than a set of element type definitions (the normal kind of DTD). An architectural form constrains conforming interchange syntaxes in such a way that instances can always be understood by receiving systems just as if they were direct instances of the meta-DTD. However, the instance need not use the same element type names used in the architectural form definitions, and many other variations are also possible. DTD designers can conform to the meta-DTD and yet, at the same time, create their own element types that inherit the processing and consistency constraints imposed by the meta-DTD.

Even though the ISO standards from which they were derived enjoy the flexibility and other benefits of architectural forms, the W3C family of XML standards does not use or support the architectural form paradigm. Accordingly, the XTM DTD has a fixed set of element types and attributes. This facilitates topic map interchange using XML-based technologies.

Hytime-specific features removed

Several features required by HyTime are not present: bounded object set-related features, link traversal attributes, etc.

The XTM DTD prefers element types to attributes

The XTM DTD uses elements, wherever possible, rather than attributes. This design choice was made possible because the number of primitives in XTM is very small and was motivated by making the syntax easy to read. As a consequence, the XTM syntax is more verbose than HyTime-based meta-DTD. HyTime-based DTDs generally prefer attributes, and the HyTime-based meta-DTD for Topic Map interchange is no exception.

The XTM DTD generalizes "display name" / "sort name" as "variant name"

The HyTime-based meta-DTD has a provision to add to each name a variant form for display and another for sort keys. This mechanism has been expanded in the XTM DTD and is now available as a generic method to add variant names to topics for any processing context by defining parameters that describe and/or identify that processing context. Display and sort are in the XTM syntax only two specific cases of this feature and are referenced as published subjects. Also, variant names can be organized into hierarchies of application contexts.

Link syntax differs

The HyTime-based meta-DTD uses HyTime varlinks, while the XTM DTD uses "simple" Xlinks

XTM provides for subject-constituting resources.

The XTM DTD boosts the notion of subject constituting resources to fully equal status with subject indicating resources. Both kinds of subjects (addressable subjects and non-addressable subjects) can participate equally easily in every construct involving a topic. In the present version of the HyTime-based meta-DTD, only subject-indicating resources can be used to declare the subjects of topics.

Types of referencing elements in the XTM DTD.

The XTM syntax contains a mechanism to express explicitly the nature of the information being referenced: If it's the subject of a <topic>, then it is referenced using a <topicRef> element. If it's a resource constituting a subject, it is referenced using a <resourceRef> element. If it is a resource indicating a subject, it is referenced using a <subjectIndicatorRef> element.

Facets are not mentioned in the XTM DTD.

In the HyTime-based meta-DTD, facets are qualifiers used to assign a property (and a value for the property) to an information object. Facets are not needed in the XTM DTD because the XTM DTD allows a topic map author to explicitly regard an information object as a subject in itself (a subject constituting resource). In the XTM DTD, therefore, it is possible to associate properties and values with information objects by means of <association> elements.

"Public subject" renamed "published subject"

What is called "public subject" in 13250:2000 is called "published subject" in XTM 1.0. This new name is less reflective of SGML jargon, but more in keeping with the meaning of the term, considering the normal semantics of the English language.