[sc34wg3] TMQL - Comments against draft dtd 2007-07-13

[Lars Marius Garshol]

I'm going through this email mainly to record new issues so that I  
can post a list of issues that doesn't lack stuff already posted to  
the list. I'll return to all open issues. I've also skipped some  
comments already settled by Robert where I have nothing to add.

* Lars Heuer
>
> Namespaces
> ----------
> - TMQL is silent about a mechanism to define namespaces. It
>   uses QNames but it seems to be impossible to define these.
>   (we have some predefined prefixes, but how does the user define
>   one?)
>   TMQL mentions the environment (section 6.3) but wouldn't it
>   be good if the user can define prefixes for a query ad hoc?
>   (see also my comments for section 6.3.)

Yes. As Robert said, the environment is going, and a prefix syntax is  
being added instead.

> 4.3. Item References
> --------------------
> - [A] item-reference ::= *
>   CTM uses the wildcard '*' to create a (more or less) anonymous
>   topic. If CTM uses '*' for that purpose, it is confusing if
>   TMQL uses the same syntax to refer to a specific topic which
>   is defined as 'tm:subject'. Either we should blame the CTM
>   editors or the TMQL editors for that confusing overlap
>   (I can imagine the answer from the TMQL-editors ;)).

Is this really an issue? They are both a kind of wildcard, even if  
they are not exactly the same. This doesn't bother me, but it's  
beginning to seem that it does bother others. I've made an issue for  
it (tmql-subject-wildcard).

Another issue is whether _ could actually be used in TMQL where * is  
currently used.

I'll come back to this.

> 4.4. Navigation
> ---------------
>
> - I wonder if we should move those axes where the 'anchor' is ignored
>   to another production. If the 'anchor' is ignored anyhow, why should
>   we allow to specify it? If an 'anchor' is specified where it is
>   ignored, an error would be more helpful than ignoring it silently,
>   IMO. If I understand the production correctly, the following
>   statement::
>
>         person << types
>
>   is equivalent to this one::
>
>         person << types <http://www.something.which/ 
> is.ignored.but.allowed>
>
>   The 'anchor' seems to have only a relevance for the following
>   productions:
>   - players
>   - characteristics

This is two issues, really:

   (1) tmql-anchor-errors: should missing anchors and ignored anchors
       cause errors? Will come back to this.

   (2) Whether to rework the grammar as suggested. Robert's reply
       does not tempt me to try to do this. If I don't hear anything
       more on this I'll just let this one drop.

> - 'locators' / 'indicators'
>
>   - Any chance, that TMQL adapts the CTM syntax for subject
>     identifiers / subject locators?
>     (TMQL uses '=' and '~' as suffix, CTM does not use ~ for subject
>     identifiers at all and uses = as IRI-prefix for subject locators)
>     Is the '~' necessary at all? Why is not every plain old IRI a  
> subject
>     identifier?

Issue tmql-iri-identifier-syntax. Dependent on CTM issue currently  
discussed offline.

> - 'reifier'
>   - Wouldn't be one tilde enough? Instead of '~~>' we could use '~>'
>   - Why is the forward shortcut ~~> defined, but not a backward  
> shortcut
>     (<~~)?

Two more issues, both of which I'd already noted on paper. :-)

   tmql-reifier-shortcuts
   tmql-reifier-reverse-axis

> - The 'characteristics' axis:
>   - Is the 'anchor' necessary at all? Isn't it possible to use
>     ``tm:occurrence`` and ``tm:name`` (or to be more exact
>     ``tm:topic-name``) as axis and ``tm:characteristic`` to retrieve
>     both: names and occurrences?

I agree with Robert here. Will not do anything more, unless prodded.

> - While writing this, I wonder if the need these uniform axes at all.
>   Why do we need the << >> axis incl. keywords, if we'd introduce some
>   specific "axes": ako, isa, <-, ->, ~>, <~ (the last four axes are
>   already part of TMQL). Well, I may be mistaken here, but we could
>   remove some (lengthly) keywords and introduce a dedicated syntax for
>   them.

Same here.

> 4.7. Composite Content
> ----------------------
> - I just want to mention, that I find the '==', '++' and '--' infix
>   operators confusing / not very intuitive
>   - for intersection ('==') I'd use '&'
>   - for union ('++') I'd use '|'
>   - for difference ('--') I'd use '-'
>
>   Well, it's just syntax and '&' and '|' are already used for 'and'
>   and 'or', but ... hmmm ... anyway ... I'll move on

I thought these were kind of nice. Again: this seems OK as is.

> - Has someone verified, that the condition (if .. then .. else ..) is
>   unambiguous (even if conditions are nested)?

Given that else is not optional there appears, as Robert points out,  
to be no dangling else problem.

> 4.10. Topic Map Content
> -----------------------
> - The topic map content is wrapped inside triple quotes ("""), but
>   CTM itself uses triple quotes. Maybe another syntax should be used
>   to wrap topic map content, otherwise the implementator has to
>   count the number of """ to decide if the topic map content block
>   is closed or if a CTM string is opened / closed.
>   Additionally, this is bad for syntax highlighers etc.
>   If TMQL uses another syntax as wrapper for topic map content, it  
> would
>   be more obvious that the content is not necessarily a string, but
>   a topic map content stream (whatever that is).

Yes, they have to be aligned (tmql-tm-content-wrapper).

> 6.3. Environment Clause
> -----------------------
> - The environment clause seems to be a string, why does TMQL not adapt
>   the directives from CTM? Maybe TMQL could add some directives for
>   setting the default topic map etc.
>   - If TMQL adapts the CTM directives, we should check if
>
>         '%' directive-name
>
>     violates the syntax for the context / environment map
>     (c.f. 5.3. Variables)

Already settled, as far as I can tell (see above).

--Lars M.