ISO/IEC JTC 1/SC 34N0811
ISO/IEC JTC 1/SC 34
Information Technology --
Document Description and Processing Languages
| TITLE: | Disposition of comments of ballot responses - ISO/IEC CD 18048 - Information technology - Topic Maps - Query Language (TMQL) |
| SOURCE: | Mr. Robert Barta; Mr. Lars Marius Garshol |
| PROJECT: | CD 18048: Information technology - Topic Maps - Query Language (TMQL) |
| PROJECT EDITOR: | Mr. Robert Barta; Mr. Lars Marius Garshol |
| STATUS: | Disposition of Comments |
| ACTION: | For information |
| DATE: | 2006-12-20 |
| DISTRIBUTION: | SC34 and Liaisons |
| REFER TO: | N0791rev - 2006-10-16 - Summary of Voting on JTC 1/SC 34 N 771 - Text for CD Ballot - ISO/IEC CD 18048 - Information technology
- Topic Maps - Query Language (TMQL) N0771 - 2006-07-13 - Text for CD Ballot - ISO/IEC CD 18048 - Information technology - Topic Maps - Query Language (TMQL) |
| REPLY TO: |
Dr. James David Mason (ISO/IEC JTC 1/SC 34 Secretariat - Standards Council of Canada) Crane Softwrights Ltd. Box 266, Kars, ON K0A-2E0 CANADA Telephone: +1 613 489-0999 Facsimile: +1 613 489-0995 Network: [email protected] http://www.jtc1sc34.org |
Editors' disposition of comments on N0791rev
The editors thank the Japanese body for its feedback and apologize for this delayed response.
Japan comments
1. General
-
The Topic Map Query Language (TMQL) is an extension of Structured Query Language (SQL) and Object Query Language (OQL), a query language allowing users to access data in Topic Maps Data Model. TMQL should focus on extending SQL regarding the select-expression language part.
While TMQL allows to use an SQL-like syntax, it is NOT designed as an extension of SQL, but instead as a dedicated query language. This implies that its design revolves around the data model for TMs, not the data model SQL was originally designed for. The conceptual problems SQL has when extended to include XML processing may serve as warning sign here. -
It needs also to extend OQL regarding the tuple-expression language part and the tm-content language part and regarding additional programming support like path epressions.
It is unclear to the editors why TMQL should orient itself towards a language which is not used at all (OQL). Also the TMDM is not an object-oriented model.
The editors welcome a clarification what extensions particularily should be added to the current TMQL draft. TMQL already has an elaborate path expression language rendering tuple results.
-
Finally TMQL should consider to follow existing XML query language regarding the xml-content query language part.
The current draft already has included an XQuery-like query structure following a FLWR syntax. This structure not only allows to generate conveniently XML-formed results, but also Topic Map-formed results. -
It is important that the types of data access for Topic Maps, Information retrieval (IR) and information filtering can be supported by the wide number of applications following and extending existing standards such SQL, OQL, XQUERY...
If the Japanese national body refers to the range of supported applications, the baseline has been outlined by the TMQL Use Cases document.
If the Japanese national body by this means that it is important for TMQL to be implementable on top of SQL, OQL, or XQuery repositories, the editors wholeheartedly agree. While this was never stated as an official requirement, there is general agreement about this among the editors and in the committee. Feedback on TMQL features which endanger this goal would be very much welcome.
If the editors have misunderstood the intent of this comment clarification is requested.
-
Thus the current proposal needs to be updated and revisited accordingly. The major risk is that TMQL might become too complicated to be wildly used and accepted by a large number of applications.
The editors feel that supporting a large number of applications and low language complexity are conflicting design goals. In that we agree that adding or removing a particular language feature has to be considered carefully.
If the Japanese national body feels that any specific functionality is too complex to implement, and should be removed, explicit feedback on this would be welcome. It would also be appreciated if a rationale for the suggested removals could be given.
2. Technical
-
Clause 3.1 Syntax Conventions The second paragraph in "3.1 Syntax Conventions" says; "The canonical level is defined using context-free grammars (EBNF,[XML 1.0])." And the production rules of TMQL uses the symbols → and ':=='. But there are not → and ':==' in EBNF[XML1.0].
This will be aligned with the XML notation in one of the next drafts. -
Whole document The symbols which are used for the shorthand notations are not familiar in the world. They should be explained clearly. And the explanation of the shorthand notations should be enhanced.
Section 3.1 will get a more thorough coverage of shorthands.
3. Editorial
-
Clause 2 Normative references Version of Unicode should be 5.0.
This will be fixed in the next draft. -
Clause 2. Normative references "IETF RFC 3987, Internationalized Resource Identifiers (IRIs), Internet Standards Track Specification, January 2005, available at http://www.ietf.org/rfc/rfc3987.txt" should be added.
This will be added in the next draft. -
Whole the document "URI" should be changed to "IRI".
This will be fixed in the next draft. -
Clause 2. Normative references "XTM 2.0" should be added.
At this stage, TMQL has no dependency on XTM 2.0. XTM 1.1 is mentioned in one example. If the example is upgraded to follow XTM 2.0, then the reference will be added. -
Clause 4.2. Atoms The datatypes defined by [XML Schema-2] should be allowed.
This issue will have to be discussed in the upcoming meetings. On the pro-side an adoption of all XSD types will simplify the integration with XML frameworks. On the negative side, an adoption puts a heavy burden on TMQL implementors as XSD implies a rich set functions and operators for these data types. -
Clause 4.3 Item References The term "subject address" should be defined.
The term "subject address" will be replaced by the now official "subject locator" in the next version. -
Clause 5.4 Special Variables The term "meta map" should be defined.
Whether this term will remain in TMQL will have to be discussed in upcoming meetings. If so, it may be replaced by "environmental map". -
Typo: Clause 3.1 Syntax Conventions, Clause 4.9 Value Expressions, and Clause Clause 6.6.4 Association Predicates "explicitely" should be "explicitly"
This will be fixed in the next draft. -
Clause 4.10.3 FORALL Clauses, in the example (2 places) "satisfy" should be "satisfies".
This will be fixed in the next draft. -
Clause 6.6.4 Association Predicates "directo" should be "direct".
This will be fixed in the next draft.