ISO/IEC JTC 1/SC34 N0254



Information Technology --

Document Description and Processing Languages


Editors Response to SC 34 N 251 – National Body Comments Received on SC 34 N 227 – Working Draft 1 on TMQL Requirements


TMQL Editors


TMQL Requirements

Project editors:

H. Holger Rath and Lars M. Garshol






13 September 2001


For information and review.


SC34 and Liaisons

Refer to:

SC34 N227, N251



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]

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]

Response to SC34 N 251

SC34 N 251 contains comments from the Japanese and UK national bodies on SC34 N 227, version 0.8.2 of the TMQL requirements. This document contains the TMQL editors' response to these comments.

Reply to comments from Japan

Comment received:

Specific query capabilities: A new subclause "Queries returning topic maps" should be added and it should say: Find all topic maps which include the topic of the query's input parameter, in case the several topic maps are specified by a mergeMap element.

When additional topic maps are merged into the root topic map by means of <mergeMap> elements their contents become part of the root topic map, and the result of reading in the root topic map is a single topic map. That is, the topic maps that are merged in no longer exist as independent topic maps. This is the case both in the infoset-based model, as well as in Newcomb and Biezunski's PMTM4.

See the reply to N 252 for more details.

Reply to comments from the UK

Ad 2:1

It is no good having human-readable queries that are not also machine-processable. An alternative machine-generatable representation, in XML, is also required. This requirement is unnecessary as 8 provides a more accurate specification of the real requirement.

It is true that queries must also be machine-processable, but this has so far been an implicit requirement. Does the UK wish to see this made explicit? The requirement that queries be human-readable is a very real requirement, since TMQL is intended to make topic map application development easier. If it fails to be human-readable it fails to achieve this aim.

A BNF-specified syntax, whether SQL-like or not, is easily machine-generatable, as decades of experience with SQL and similar syntaxes shows. There may be other arguments for an XML-based syntax, but the editors do not consider this to be a persuasive one.

2:8 is a requirement on the text of the TMQL standard; 2:1 is a requirement on the syntactical form of TMQL queries. They are thus entirely orthogonal.

Ad 2:3

Any abstract TMQL data model must take as its start point the Topic Map Data Model proposed in N229 (as is indicated under the Model and Algebra heading below, where point 2, regarding extension of other models, is the most important statement).

The TMQL data model will indeed take the topic map data model as its starting point. After the Montréal meeting it seems that this model will be based on N229 and N243. Regretfully, SC34 has so far failed to provide any formal existence for this work (see the reply to N252), and so the TMQL requirements document has so far been unable to properly refer to it. It is hoped that this will be rectified eventually.

In short, the editors agree with the comments from the UK national body, but find themselves unable to update the requirements document to reflect its agreement. SC34 is urged to provide the topic map data model work with a formal existence.

Ad 2:6

Remove "providing ISO regulations provide". ISO regulations allow 2 part standards where the second part extends the first. ISO is not the arbiter of whether or not the user community needs a standard for updating topic maps. However, such features must take into account international data privacy and copyright laws. Update can only be acceptable where metadata relating to ownership of the data is part of the topic map. At present this is not the case.

The offending sentence has been removed in version 1.0.0 of the requirements document (N249).

Ad 2:7

This simply duplicates 4 and should be removed.

What requirement 2:7 is saying is that the TMQL standard should not unecessarily constrain the form of implementations, and this applies not only to their external interfaces, but also to their internal implementation strategy. The standard should not require implementations to evaluate queries in a certain way, for example, as long as they produce the specified result.

It might be argued that requirement 2:4 is implied by requirement 2:7, but the editors feel that 2:4 is important enough to warrant inclusion even though this may be the case.

Ad 3.1:3

TQML should not define "how TMQL processors should react to them [error situations]." This must be application dependent.

To some extent reactions to error situations must be implementation-dependent, but the TMQL standard should make specific requirements as to whether processors are required to halt processing or to continue processing in some specified way. The standard should not make any requirements beyond this.

The editors suggest that the requirement can stand as it is.

Ad 3.3:5

(This requirement is 3.3:7 in N249 (version 1.0.0).)

Add "When returning information not present in the queried topic maps the source of the additional information shall be clearly identified".

Where should it be clearly identified? In the query results or in the standard? It is as yet unclear how a feature like the one described in this requirement may work, but if it is, as seems likely, analogous to SQL views, the query already contains the information about where the additional information came from, and so no further identification should be necessary. The editors agree that the TMQL standard should clearly identify the source of such additional topic map information, but are uncertain as to whether the requirements documents needs to state this explicitly.

Ad 3.5:2

Within parentheses, change "will" to "should". (If the published data model only supports 13250 then the XTM work would have to be an extension of the published model.)

SC34 has so far, regretfully, failed to provide a requirements document for the topic map data model, but the TMQL editors believe that the topic map data model must support XTM. Until they are proven wrong the current wording ("will") is correct.

The editors urge SC34 to create a requirements document for the topic map data model work in order that question like this one can be clarified and discussed in the appropriate manner.