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

[Lars Heuer]

Hi Robert,

[...]
>> 4.4. Navigation
>> ---------------
>> 
>> - [B] step::= >> instances 
>>   'instances' is not part of production [18]. Either this axis should
>>   be added or the forward direction should be removed, and therefor
>>   only '<<' 'types' should be a valid axis.

> The way the shortcuts are defined in TMQL is like this

>     "shortcut"  expands to "longer, canonical form"
[...]
> So this 'shortcut' introduces an 'instances' axis as the reverse
> direction of the 'types' axis.

Yes, I understood it, but 'instances' is not mentioned in the
production [18]. That was my point. It is not clear if someone can use
'types' and 'instances' interchangeable (with interchanged '<<' '>>'
tokens). Maybe it is clear but I do not understand it. :)


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

> Yes. Some axes NEED an anchor. Some CAN have one, but provide a
> default. Others do not need one, it is always IGNORED.

Yes, I still favour an error instead of silently ignoring these
anchors.

> And yes, you can reform the productions to be sensitive for each
> different step whether it needs an anchor or not. This does NOT help
> the presentation IMO and adds 10 more productions.

I don't believe so, since the anchor is used in two productions, only.
All other productions ignore it.


[...]
>>   The 'anchor' seems to have only a relevance for the following
>>   productions:
>>   - players
>>   - characteristics

> Sounds about right. With the current setup, though, we would have the
> freedom to add meaning to an anchor easily.

Well, if we do not have a use case for a meaning, remove it. If
someone comes up with an intelligent idea how we can use the anchor,
we can add the anchor in TMQL v2.0.

[...]
>> - 'reifier'
>>   - Wouldn't be one tilde enough? Instead of '~~>' we could use '~>'

> I like tildes. :-) The more, the merrier. Seriously (if one can be
> serious about syntax), as long as it nicely symbolizes a "zoom"
> operation (this is what reification in TMs is about) I would be happy.

I'd be happy, with one "~" instead of two. ;)


>>   - Why is the forward shortcut ~~> defined, but not a backward shortcut
>>     (<~~)?

> That would be possible and that was already an issue

>    http://www.jtc1sc34.org/repository/0827.pdf

>    "Add inverse reification shorthand"

> As there was no response and I figured that it is of limited use, I
> dropped the idea.

IMO it is strange to offer a forward shortcut but omit the backward
shortcut since such an shortcut does no harm.


>> - 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?

> You mean you want to introduce two new axes "name" and "occurrence"
> instead of the one "characteristics"? Also that was discussed in Oslo.

No, my suggestion was to loose the need for the 'anchor'.

    tm:name ako tm:characteristic

    tm:occurrence ako tm:characteristic

So, you'll get with "tm:characteristic" names and occurrences.

And you can use the postfix filter for filtering by type (see my
examples in the original mail).

The 'anchor' seems to be useful for the roles / players navigation but
all other productions can live easily without it (and some ignore it
at all as already stated above).

And iff we drop the (ignored) anchor, we get only one production which
need it. And your argument, that you'll need 10 more productions would
be disproved. ;)

Seriously: I do not see an advantage if the 'anchor' is kept if you
get the same results with postfix filters.


[...]
> Replacing it with you solution would not minimize the number of
> concepts. If we would get rid of the 'control anchor' altogether,
> there would be a gain.

As said, I think, the anchor is needed for only one production
(player/roles).


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

> It should be, because the keywords act as bracket. Also not that the
> 'else' is NOT optional. That could have been a point of possible
> confusion:

Aha! From the current draft I got the impression that the else-branch
*is* optional.

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

> Yes, they should use the same mechanisms. Not only for this.

Hmm... Does this answer my question? ;) The point was, that """ is
used by CTM, so you'll get:

     return """
            where-the-wild-roses-grow
            lyrics: """As I kissed her goodbye, I said, "All beauty must die"
                       And lent down and planted a rose between her teeth
            """
     """

Which should be avoided. TQML could use for example "[[" "]]" to mark
CTM content.


[...]
>> 6.3. Environment Clause
>> -----------------------
>> - The environment clause seems to be a string, why does TMQL not adapt
>>   the directives from CTM?

> Because they do not make any sense in the context of TMQL? The closest
> to being useful is the prefix, but, well ... see above.

>>   Maybe TMQL could add some directives for
>>   setting the default topic map etc.

> Isn't there the FROM clause doing that?

Sure, but I wonder how a user can define the 'default' topic map if
the FROM clause is missing. TMQL refers often to the 'current context
map' and I thought this topic map is declared within the environment
somehow.

Best regards,
Lars
-- 
http://www.semagia.com