[tmql-wg] TOMA: comparison with TMQL
rp at spaceapplications.com
Wed Feb 21 04:08:38 EST 2007
In order to increase readability, I included only the interesting
Robert Barta wrote:
>> :-) This example has been provided in order to explain why the following
>> syntax has been developed:
>> So the above example can be written in Toma as:
>> select $topic
>> where id(?little_finger?).$$<-(connect_to)->$$
>> .$$<-(connect_to)->$$ = $topic;
>> select $topic
>> where id(?little_finger?)
>> .connected<-(connect_to)->connected = $topic;
>> Which is at least as elegant as:
>>> In TMQL I would do
>>> $f = little_finger
>>> & $f <- connected [ ^ connect_to ] -> connected == $f'
>>> & $f' <- connected [ ^ connect_to ] -> connected == $f''
>>> & $f'' <- connected [ ^ connect_to ] -> connected == $f'''
> Elegance is on-par, I agree, but with the price of an _additional_
> syntax construct.
What _price_ of an additional syntax construct? If you refer to the left
arrow, it is true that Toma didn't have the left arrow in the past, and
now it does. However, this was added to _simplify_ the syntax (making
the association expression a real path expression with input and
output). So what is the price to pay here? And how TMQL avoids this price?
>>> What I found slightly difficult to grasp is that filtering is done quite
>>> differently, depending on what to filter. To get one particular name from
>>> list, one would do this via
>> The different syntax points to different kind of filtering.
>>> In TMQL filtering is always done with . Fullstop.
>> So how do you tell the engine that you want a topic of type t1 and scope
>> s1 and later for a topic of type s1 and scope t1?
> In TMQL to get all is-employed-by assocs you do (fully written out)
> %_ [ . >> classes == is-employed-by ]
> ^ ^ ^ ^
> take the map |
> | | |
> take each item
> | |
> find all classes
> and check whether there is an overlap with is-employed-by
> To find then all in a particular scope, same thing, but different navigation
> %_ [ . >> classes == is-employed-by ]
> [ . >> scope == my-database ]
> Since these simple filters occur often, there is a shortcut doing the
> same thing
> %_ [ ^ is-employed-at ] [ @ my-database ]
> And this is also shorter to write
> // is-employed-at [ @ my-database ]
> So the axes make all the difference. And they can be used anywhere,
> not only inside a filter.
And you end up with syntax for scope (@) and for class (^), don't you?
>> Could you give an example of the following in TMQL:
>> select $topic.bn@$scope, $scope.bn@$scope2, $scope2.id
>> where $topic.bn = 'lung';
> Same scheme:
> "lung" \ name / name ( . , . @ / name ( . , . @ ) )
> Not sure what it does, though :-)
What I meant is to select a topic that its basename is 'lung' and then
to provide three columns:
The first column gives the basenames of that topic.
The second column gives the basenames of the scopes of each of the
basenames in the first column.
The third column gives the scopes of the basenames of the _second_ column.
The introduction of the variables in the selection part allows to have
columns that depend on other columns.
>> si('http://...') is a subjectIdentity literal. It can start a path
>> expression chaining: it has output which is the topic which has the
>> subjectIdentity 'http://.../'. But it takes no input. So it cannot be
>> chained after $topic.
>> Note that you have the path expression .si which takes as input a topic
>> and output its subjectIdentity.
> What would I have to do to address a topic via its subject indicator
> (identifier) and what for a topic with a subject locator?
Currently Toma has only the topic literal si() which provides a topic
with certain subjectIdentity (there is a mistake in the current manual
about this literal where it is refering to subjectIndicator. It will be
You have, though, path expressions for
subjectIdentity ResourceRef .si.rr
subjectIdentity subjectIndicatorRef .si.sir
subjectIdentity topicRef .si.tr
(yes... Toma bases itself on XTM 1.0 mainly, although it does not ignore
>> The select you quote above, tries to take any descendant of the
>> topic device, that it: any instance of device, any instance of a
>> subclass of device, any instance of a subclass of a subclass of
>> device etc.
> Yes, this is implicit in TMQL _EVERYWHERE. I would claim that most
> applications will need this behaviour.
Ha! if it is agreed that there is no need for distinction between types
(so those classes that have direct instances) and classes (those classes
which have no direct instances but only subclasses), Toma could give up
one of the path expressions type() or super(). But is there a consensus
that this distinction is no longer of any importance (after all it plays
a great role in XTM1.0).
>> In order to find all associations of type part-whole you should write in
>> select distinct $a where exists $a(part-whole)->$$;
> The 'distinct' is not really necessary here, right?
We ask for all existing _players_ playing in association $a of type
part-whole playing whatever role $$. So if we have two players or more
per certain association, we will get that association id more then once.
Therefore the DISTINCT.
> In TMQL, there is no distinction between assocs and topics (TMRMish
> interpretation) in that they are all 'things'. So a
> // part-whole
> gives you all things which are an instance of part-whole. Could be
> topic, could be assoc, could be name, could be occurrence. If you
> want only topics, then one has to say so.
This indeed cannot be done in Toma.
>> We do not want to get as a result for $topic the topic 'little_finger',
>> but without this rule, we would get it (because 'little_finger' is
>> connected to whatever which is connected back to 'little_finger').
>> I wonder how TMQL solves this.
> TMQL does not try to do that. Not only, because writing maps ( =
> massive effort) and then using connections like (is-connected-to) is
> like flying with a helicopter to the bathroom. ;-)
I tend to disagree here. This can be a very valid question: to which
organs the stomach is connected indirectly. Or how two organs are
> I regard this 'one hop must be different from the next' as _VERY_
> application specific and relative to how someone models his content.
I thought that questions like "which topic is associated to topic t1
through N associations" is a common question, and there the user usually
won't expect to get back t1.
>>> -- XML and TM content
>>> TOMA obviously cannot generate TM or XML content. Now Rani will claim that
>>> is a template thing. But it is not, I think, and even if it were, for
>>> performance reasons this should be part of the language.
>> Rani indeed claims that this is a template thing :-)
> Gotcha! :-))
:-) there is a long history here. I just checked that you remember :-)
>> I have put as a focus to have Toma as simple and as small as
>> possible. It is TMQL, TMCL and TMML and nothing else. I assumed
>> that users that want to create applications using Toma or any other
>> TMQL will use in addition other technologies (Java, Perl, Python
>> etc.). Each of those technologies provide sets of techniques and
>> methodologies to create XML content as well as any other
>> content. Why to extend the language to include another such
>> technique? And what are the performance reasons here?
> Let's assume we do it as you suggest. So what the application then
> gets is a sequence of tuple values (strings, integer, topic,
> If I needed this in XML form then I would take these values, would
> inject them into a template. That result has to be XML-parsed (not?)
No. You parse your template onces, and then use the already parsed
version of it (i.e. syntax tree) to generate the populated instance.
> __EVERYTIME__ I do that, for 500 rows, 500 times parsing of the
> essentially the same structure. And then these fragments have to
> collected into a document (that is cheap).
> Even if these template engines allow pre-parsing (I know of none), you
Class::Skin - http://search.cpan.org/~rani/Class-Skin-0.05/Skin.pm
but, I hope, also many many others.
> still have the overhead of taking the values out of a TMQL processor
> and injecting them into the template. And I suspect that many TMQL
> processors will copy the data values before handing them over to the
> application (never entrust an application engineer with the data
> structures inside the DB ;-), so this will also carry the copying
> But it gets worse, much morse actually, if the result you want to
> generate is NOT very regular, say, like in a book. In your scenario
> the book results would have to be flattened into a sequence first
> (maybe containing a lot on NULL values), and then a program will have
> to have a lot of
> if not NULL then _expand_template (....)
> And for TM content, by definition the content is quite irregular.
This argument is true for any situation where you choose to involve more
then one environment. Still I don't think that there is an environment
that provides all the solutions for any problem.
In addition, some of the costs you point to will be payed anyway by the
engine that implements this kill-all-TMQL.
And your TMQL loose points with the (I think many) users that will
prefer to use the environment they are used to/think is more
appropriate/have to use because of legacy issues etc.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 317 bytes
Desc: not available
Url : http://www.petesbox.net/pipermail/tmql-wg/attachments/20070221/da373238/rp-0001.vcf
More information about the tmql-wg