[sc34wg3] Response to SC34 N 251

Thu, 13 Sep 2001 09:31:29 +0200

This is a multi-part message in MIME format.
--------------090605090001040002060106
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi everyone,

here is Holger's and my response to SC34 N 251, national body comments
on the TMQL requirements. Sara, and/or Jim, could you give this a number
and put it in the document registry?

--Lars M.

--------------090605090001040002060106
Content-Type: text/html;
 name="0251-reply.html"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="0251-reply.html"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>Response to SC34 N 251</title>

<style type="text/css">
th {
  text-align: left;
  vertical-align: top;
}

h1, h2, h3, h4 {
  font-family: Verdana, Helvetica, sans-serif;
}

body {
  margin-left: 10%;
  margin-right: 10%;
  margin-top: 48pt;
}

dt {
  font-weight: bold;
}
</style>
</head>
<body>

<h1>Response to SC34 N 251</h1>

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.

<h2>Reply to comments from Japan</h2>

<p>
Comment received:
</p>

<blockquote> 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.
</blockquote>

When additional topic maps are merged into the root topic map by means
of <tt>&lt;mergeMap></tt> 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.

<h2>Reply to comments from the UK</h2>

<h3>Ad 2:1</h3>

<blockquote>
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.
</blockquote>

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.

<h3>Ad 2:3</h3>

<blockquote> 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). </blockquote>

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.

<h3>Ad 2:6</h3>

<blockquote> 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. </blockquote>

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

<h3>Ad 2:7</h3>

<blockquote>
This simply duplicates 4 and should be removed.
</blockquote>

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.

<h3>Ad 3.1:3</h3>

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

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.

<h3>Ad 3.3:5</h3>

<p>
(This requirement is 3.3:7 in N249 (version 1.0.0).)
</p>

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

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.

<h3>Ad 3.5:2</h3>

<blockquote> 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.)</blockquote>

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.

--------------090605090001040002060106--