[tmql-wg] TOMA: comparison with TMQL
rp at spaceapplications.com
Fri Feb 23 05:52:13 EST 2007
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 = $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.
> and to make sure that the associations involved are different, the original
> solution [ A ]
> $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 ]
> $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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 317 bytes
Desc: not available
Url : http://www.petesbox.net/pipermail/tmql-wg/attachments/20070223/25c4c85c/rp.vcf
More information about the tmql-wg