The requirements for the programming model are generated from the need to get a potentially very wide audience of developers up to speed with topic map technology as quickly as possible. For this reason, the core focus of our requirements are in two areas: Simplicity and Practicality.
The topic map programming model should be simple to explain and easy to learn. This means that the number of classes and operations should ideally be kept low and that the API should only focus on covering the topic map model itself. Complex extensions such as query languages and inference rules are definitely out of scope. It was more difficult to draw the line in the grey area of other, more common, extensions such as transitive association types and type hierarchies. However, we believe that these common extensions should be easily implemented on top of a core API which is focused only on the representation of the topic map model and so have no place in the API we propose to develop.
To further simplify the programming model, it was felt to be important that the constructs in the programming model should be closely parallel to those constructs found in the syntax. By making parallel structures in the programming model to those which exist in the topic map syntax, we enable programmers who have looked through the XTM specification to quickly get a 'feel' for the API.
The API could easily support common topic map operations such as import and export of a serialised form of the topic map; association traversal and direct manipulation of topic map constructs. Providing additional practicality such as merging, indexing and filtering operations within this core API would sacrifice the simplicity principle. By providing a solid foundation, the common extensions should be easy to implement in a layered manner. The precedence for this can be clearly seen in the XML family of standards, with implementations of linking (XLink), path expressions (XPath) and more complex operations such as transformation (XSLT) all being typically implemented upon the DOM abstraction of the XML document.
The programming model must support all those topic map operations which are the most fundamental parts of topic map applications. This means that the programming model must provide the means to achieve at least the following:
Topic map parsing - APIs for reading from a serialized syntax into some internal data structure.
Topic map manipulation - APIs for manipulating the constructs of topic maps (topics, associations, occurrences etc.)
Topic map serialization - the reverse of parsing, these are APIs for creating a serialized version of the internal data structures used to represent the topic map.
The parsing and serialization of topic maps can be considered
"utility" functions which are useful additions to a core topic map API.
Serialization is merely the process of walking a topic map data structure using
the API and generating the appropriate XML syntax to represent the constructs
found there. Parsing is the reverse, although the parsing process must also
include the processing of the raw parsed data into a topic map in accordance
with the requirements of the XTM Specification
Such an programming model should also provide a solid foundation on which ancillary standards and systems may be implemented. The precedence for this is clearly set by the XML family of standards - systems which implement XSLT and XPath are typically built upon a DOM implementation. The ancillary standards for topic maps are not yet fully defined, work is already started on a query language (TMQL) and a schema/constraint language (TMCL).
To set some boundaries on what should be included in a the core topic map programming model, it was decided to constrain the level of functionality that the programming model would be expected to provide. For this reason, the models developed here do not directly address:
Representation of the mergeMap construct and the topic map merging process
Representation of templating mechanisms.
Indexing of topic map constructs.
Support for transitive association types or type hierarchies.
Maintenance of lexical information about the source XTM document
In many respects, these constraints are common requirements for a topic map programming model, regardless of its form, and this paper is concentrating on the potential differences between various forms of programming model, rather than on the commonalities between those forms. However, the constraints do serve as a useful guide in determining the practicality of a given model as these are all higher-level functions which it must be possible to build on the core programming model.
The development and analysis work presented here also does not delve into the extremely important API issues relating to object deletion, referential integrity, transaction support, duplicate suppression and the handling of merges which take place as a result of manipulating API objects directly. Again, these are all issues which must be addressed regardless of the API used.
Finally, the APIs developed here all take the same approach to the question of multi-valued properties. All properties which may have zero or more items as their value give rise to three API methods - a get() method which returns an array of the value type; an add method() which takes a single parameter of the value type and has no return value; and a remove() method which takes a single parameter of the value type and has no return value. A practical API may also include a set() method and/or a clear() method to further manipulate the property. Additionally, the return type from the get() method could be implemented to return a collection object or an iterator object - if returning a collection object, a design decision must be made as to whether that collection is read-only or read-write.
| Up: Developing A Topic Map Programming Model | |
| Previous: Relationship to TMQL | Next: Architecture Proposals |