ISO/IEC JTC 1/SC34 N0254
ISO/IEC JTC 1/SC34
Information Technology --
Document Description and Processing Languages
|
Title: |
Editors Response to SC 34 N 251 – National Body Comments Received on SC 34 N 227 – Working Draft 1 on TMQL Requirements |
|
Source: |
TMQL Editors |
|
Project: |
TMQL Requirements |
|
Project editors: |
H. Holger Rath and Lars M. Garshol |
|
Status: |
|
|
Action: |
|
|
Date: |
13 September 2001 |
|
Summary: |
For information and review. |
|
Distribution: |
SC34 and Liaisons |
|
Refer to: |
|
|
Supercedes: |
|
|
Reply to: |
Dr. James David Mason |
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.