[tmql-wg] TOMA: comparison with TMQL

[Robert Barta]

On Fri, Feb 23, 2007 at 11:52:13AM +0100, Rani Pinchuk wrote:
> >>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.

Let me turn this around: If a language mandates a certain distinction
on the use of the 'isa' and 'iko' inside maps, then it is stepping
over the boundary given by TMDM. TOMA can do this, TMQL cannot.

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

The - general - rules are

  - variables with different names are independent and can bind to different values
  - variables with the same name can only bind to one and the same value
  - variables where the names only differ in 's MUST  bind to DIFFERENT values

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

They may be pragmatically proper for TOMA, but TMQL must allow also
'absurd' (that one actually is not so absurd, think quality assurance
and validation) use cases. As language creator you are not entitled to
'the faith'.

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

OK, let's talk code here

If I would use Class::Skin, it would go like this:

my $q = TM::QL->new  ("select $p / name ...");

my $dom = new DocumentFragment;
foreach my $r ($q->eval) {
  my $t = $skin->parse (xxx => $r->[0], yyy => $r->[1]);
  my $n = $xml_parser (text => $t);
  $dom->append ($n);
}

# then embed this whole thing into the root

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

But this is a functionality which is ALWAYS the same. And it gets EXTREMELY
cumbersome if that goes several levels deep:  You would have to have nested
loops.

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

There is ABSOLUTELY no further flexibility, because injecting values into
an XML fragment is exactly this. TMQL definitely becomes simpler, but real
applications will have to deal with the conversion. Sounds hardly like a
big advantage ;-)

Try it yourself by solving this:

  "Iterate over all music groups in the map, find all the group members
   and list the instruments they are playing. Guitarists detail whether
   bass or not."

Any XML structure with 3+ levels will demonstrate my point.

\rho