[tmql-wg] TOMA: comparison with TMQL

[Rani Pinchuk]

In order to increase readability, I included only the interesting 
excerpts below:

Robert Barta wrote:
>>>
>> :-) This example has been provided in order to explain why the following 
>> syntax has been developed:
>>
>> 		.role1<-association_id(association_type)->role2
>>
>> So the above example can be written in Toma as:
>>
>>   select $topic
>>     where id(?little_finger?).$$<-(connect_to)->$$
>>                              .$$<-(connect_to)->$$
>>                              .$$<-(connect_to)->$$ = $topic;
>>
>> or
>>
>>   select $topic
>>     where id(?little_finger?)
>>       .connected<-(connect_to)->connected
>>       .connected<-(connect_to)->connected
>>       .connected<-(connect_to)->connected = $topic;
>>
>> Which is at least as elegant as:
>>> In TMQL I would do
>>>
>>> where
>>>  $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 
>>> the
>>> 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
> axis:
> 
>   %_ [ . >> 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 
fixed soon).

You have, though, path expressions for
    	subjectIdentity: 				.si
	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 TMDM).

>> 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 
>> Toma:
>>    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 
connected.

> 
> 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 
>>> this
>>> 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,
> whatever).
> 
> 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
> cost.
> 
> 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 (....)
> 
> stuff.
> 
> 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.

Kind regards,

Rani
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rp.vcf
Type: text/x-vcard
Size: 317 bytes
Desc: not available
Url : http://www.petesbox.net/pipermail/tmql-wg/attachments/20070221/da373238/rp-0001.vcf