[tmql-wg] TOMA: comparison with TMQL

[Robert Barta]

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

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