# [tmql-wg] TOMA: comparison with TMQL

Robert Barta rho at bigpond.net.au
Thu Feb 22 05:35:01 EST 2007

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.

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

Yes, but this is necessary anyway as it must be possible to reach into
every corner of the TMDM. Alone the navigational axes for climbing
through TMDM take up 5 pages in the spec. But there is no way around that.

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

:-) Sure, I meant how useful that is practically.

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

Ah, OK. TMQL has no affiliation with anything XTMish anymore. So there
only TMDM-compatible identification mechanisms are offered.

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

> >>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. What I meant, was that the terms 'is-connected-to', 'connected' is a very weak choice for types/roles in associations, because everything in an association is a connected thing and an association by definition connects. > >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;

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.

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

\rho