[tmql-wg] Comments against TMQL draft 2006-02-22

[Lars Heuer]

Hi,

As promised earlier, here some comments against the TMQL-draft dtd.
22.02.2006.

I tried to read the whole document and started with great enthusiasm,
but due to the lack of time I gave up. :) Maybe I come back later with
more issues.

Regards,
Lars


TMQL Issues
===========

General
-------
- TMQL is IMO case-sensitive, but it is never stated somewhere
  It should be stated somewhere if the language is case-sensitve 
  or not.

- The TMDM namespace seems to be the default namespace. Otherwise
        jack / name 
  cannot work (since "name" is not a keyword). 
  But it is never stated that the TMDM namespace is the default one
  and does not need the "tm" prefix.

- The draft is (intentionally) silent about the data which is
  returned if a query generates topics, not their characteristics.
  Do the editors consider to add a section which clarifies this?



3.2 Ontological Commitments
---------------------------

- Prefix "tm"
  The prefix "tm" cannot be bound to 
  "http://psi.topicmaps.org/iso13250/glossary/"
  but must be bound to "http://psi.topicmaps.org/iso13250/model/"
  
  Reason:
  The "/glossary" namespace just contains glossary terms but not 
  TM-datamodel terms
  
  IMO the prefix should be renamed to "dm" since the important part 
  is "Data Model", not "Topic Maps".

- Prefix "xsd"
  IMO the prefix "xsd" should be "xs" since nearly all XML standards
  use "xs"

- Prefix "tmql"
  Why is it not just "ql"?


4.2 Atoms
---------
- "This International Standard recognizes natively a small set of 
  primitive data types..."
  I.e. "qname" is neither a native nor an primitive datatype in 
  "XML Schema Part 2: Datatypes Second Edition"-sense.
  
  
- [6] date ::= xsd:dateTime
  "date" should be "xsd:date", "xsd:dateTime" is a different 
  datatype.

- [7] iri
  IRIs must be encapsulated by '"'; why?
  In Leipzig (10/2006) the committee decided that IRIs are detectable
  and IRIs do not have to be quoted for CTM. Why are IRIs are not 
  detectable by a TMQL processor?

- "For all types, a IRI can..."
  "For all types, a_n_ IRI can"

- EXAMPLE
  "http://example.org/something"  (xsd:anyURI)
  It is unclear why the provided string is interpreted as
  xsd:anyURI.
  IMO the provided string is ambiguous because it could also be
  interpreted as literal with datatype xsd:string
  
  2005-10-16T10:29  (xsd:date)
  The provided value is neither a xsd:date nor a xsd:dateTime
  
  Valid date: 2005-10-16
  Valid dateTime: 2005-10-16T10:29:00


- "If a prefix is used to form a QName, then no blanks between the 
  prefix and the following identifiers are allowed."
  
  IMO this rule should be moved to a "QName" rule

4.4 Navigation
--------------
- [15] axis
  Several axis use a terminology (i.e. "classes") which is not 
  aligned to TMDM.
  Consider to align the axes names with the TMDM-terminology

- [h] indicators
  I wonder if we need two syntaxes for subject identifiers. The user
  may use either a plain URI or an URI with the "~" suffix. Isn't a
  plain URI enough? Why do we need the "~"?

- [i] reifier
  Isn't one "~" enough? So, we'll get "~>" And if we eleminte the "~"
  from [h] we can write reifiers even more compact "~". But I don't 
  mind if the "~>" looks better :)


4.7 Composite Content
---------------------
- [19] content
  Reasons why the operators "++" and "--" are not "+" and "-"?
  
  IMO it is a bit confusing that the equality operator "==" is 
  mentioned in this section together with the concatenation and 
  subtraction operators.


4.10 Topic Map Content
----------------------
Do we need this section at all? How is CTM different from any other
textual content?


4.13 Boolean Expressions
------------------------
- [34] boolean-expression
  Operators "&" and "|": In a previous context the "OR" operator was
  "||". Which one is correct?
  
  IMO && and || look better and are more common in other languages, 
  but I don't mind. :)


5 Query Contexts
----------------
"%__" (current environment map) and "%_" (current context map) are not
very readable resp. distinguishable.


-- 
http://www.semagia.com