[tmql-wg] TOMA: comparison with TMQL

[Rani Pinchuk]

Robert Barta wrote:
> On Wed, Feb 21, 2007 at 10:08:38AM +0100, Rani Pinchuk wrote:
>>>>  select $topic
>>>>    where id(?little_finger?)
>>>>      .connected<-(connect_to)->connected
>>>>      .connected<-(connect_to)->connected
>>>>      .connected<-(connect_to)->connected = $topic;
> 
>> 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.
> 
> Yes, that is what I mean. To solve some specific problem, one specific
> syntax has been introduced.
> 
>> output). So what is the price to pay here? And how TMQL avoids this price?
> 
> The price is complexity of the syntax. And TMQL _tries_ to avoid that
> by being as orthogonal as possible.
In this specific case, I think introducing this specific syntax made 
Toma more orthogonal. After this addition, association path expression 
is indeed a path expression with input and output.
So the historical evolution of Toma (the fact that I didn't think about 
this syntax in the first place) is not relevant here.

>> 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).
> 
> Hmmm, this question (types vs. classes) is more a modelling issue and
> how 'isa' and 'iko' are used in maps, rather than a TMQL issue.
> 
I am not sure I understand this statement - if TMQL does not support 
this distinction (between types and classes), then you cannot use such 
model with it.


>>> 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.
> 
> But, sure, such questions are important. And they can be solved with TMQL,
> but all with onboard means, not special-purpose syntax. So to achieve this
> 
>    > >select $topic
>    > >   where $a(connect_to)->connected = 'little_finger'
>    > >   and $a(connect_to)->connected = $p1
>    > >   and $p1 not in ('little_finger')
>    > >   and $b(connect_to)->connected = $p2
>    > >   and $b(connect_to)->connected = $p1
>    > >   and $p2.bn != $p1.bn
>    > >   and $c(connect_to)->connected = $p
>    > >   and $c(connect_to)->connected = $p2
>    > >   and $p.bn != $p2.bn
>    > >   and $a != $b
>    > >   and $b != $c;
> 
:-) Ha! please do not quote this example again :-)
This example comes to explain why the <- was needed (so again, to 
explain the change made in the early Toma). This example should be 
written in Toma as:

   select $topic where $topic.connected<-(connect_to)->connected.
                             .connected<-(connect_to)->connected.
                             .connected<-(connect_to)->connected =
                                     'little_finger';

> and to make sure that the associations involved are different, the original
> solution [ A ]
> 
>     where
>       $f = little_finger
>     & $f   <- connected [ ^ connect_to ] -> connected == $f'
>     & $f'  <- connected [ ^ connect_to ] -> connected == $f''
>     & $f'' <- connected [ ^ connect_to ] -> connected == $f'''
> 
> has to be expanded to [ B ]
> 
>     where
>       $f = little_finger
>     & $f   <- connected [ ^ connect_to ] == $a   & $a  -> connected == $f'
>     & $f'  <- connected [ ^ connect_to ] == $a'  & $a' -> connected == $f''
>     & $f'' <- connected [ ^ connect_to ] == $a'' & $a''-> connected == $f'''
> 
> You see, the same trick with the variables, no special syntax. And in [ A
> ] I just did not care about the associations.
Just to understand the syntax here: $a cannot hold the same value as $a' 
or $a''? So what is $f, $f'' and $f''' ?
In any case, I cannot think of a use case where the user will want to 
see in such a query the same associations and therefore I think that the 
assumption Toma make here makes sense.

> 
>>> __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
> 
> Class::Skin returns me a DOM fragment node? The only thing which is parsed
> there is your own code inside a template, maybe. But the result is text.
> And if I need a DOM instance I have to XML-parse it, right?
> 
> And this is exactly what TMQL does not.
I am afraid I don't get your point.

If you want TMQL to be able to provide an XML without extra cost, 
classes like Class::Skin can do that for you without that extra cost.

If you want to have TMQL to provide a DOM fragments, you can look for 
similar classes that take as input XML and data, pre-parse the XML into 
a syntax tree and then generate DOM fragments.

Actually any mechanism you could add to TMQL in order to wrap the 
results of it in some manner could be also taken out of TMQL without 
extra cost (apart from copying the output data to the external module 
that will wrap it - cost that is in my opinion negligible). But when you 
take it out of TMQL, you make TMQL simpler and more flexible, and leave 
for the user the choice to use whatever facilities he finds appropriate 
for his development - I consider this a big advantage.

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/20070223/25c4c85c/rp.vcf