[tmql-wg] Comments against TMQL draft 2006-02-22

[Robert Barta]

On Wed, Mar 07, 2007 at 06:04:17PM +0100, Lars Heuer wrote:
> [...]
> >    jack / name
> 
> > should work is that 'name' is a _valid_ item reference of a topic in
> > every map(!) for the TMDM concept
> [...]
>      http://psi.topicmaps.org/iso13250/model/topic-name
> 
> 
> But your definition seems to match the concept of a default namespace
> with an additional alias "name" for "topic-name". In fact you're using
> the TMDM namespace as default namespace. I don't see a difference. The
> only difference is, that you use a meta-topic map to import the
> identifiers for "name", "occurrence" etc.

If I write

   jack

then my expectation is that the processor will look into the currently
queried map. So the default namespace would be (again, TMQL does not
use conventional namespacing) that of the current contect map.

So far we agree, I think.

But I would argue that

   name

and

   occurrence

fall into the same category: they *also* are in the map. [ For reasons
outlined elsewhere. ]


> [...]
> >    lheuer isa person
> >    ! irc-nick: lheuer
> >    ! fullname: Lars Heuer
> 
> > Here I would argue that implicitely
> 
> >    irc-nick iko name
> >    fullname iko name
> 
> Jep. But it seems not to be a CTM issue but an general issue for all
> Topic Maps syntaxes, resp. Topic Maps itself.

Yes, it applies to *all* deserialization. But CTM could be the first
which gets it right ;-)

> >> - Prefix "tmql"
> >>   Why is it not just "ql"?
> 
> > No particular reason, except maybe that TMQL is already a mnemonic. ql
> > is not.
> 
> Ok. Well, I have no strong feelings here, just thought it would be
> nice to define all namespaces with two letters. ;)

That would look like this

  ql
  cl
  ct
  dm
  rm

Hmmm, does not look too bad.

> >> 4.2 Atoms
> >> ---------
> >> - "This International Standard recognizes natively a small set of 
> >>   primitive data types..."
> >>   I.e. "qname" is neither a native nor an primitive datatype in 
> >>   "XML Schema Part 2: Datatypes Second Edition"-sense.
> 
> > Probably I do not understand something properly, because QNames are an
> > XS type:
> 
> >     http://www.w3.org/TR/xmlschema-2/datatypes.html#QName
> 
> > I'm a bit flaky on this one, so help/education is welcome.
> 
> Namespaces in XML
> <http://www.w3.org/TR/1999/REC-xml-names-19990114/#dt-qname> has the
> following grammar for QNames:
> 
>           [6]     QName      ::=    (Prefix ':')? LocalPart
>           [7]     Prefix     ::=     NCName
>           [8]     LocalPart  ::=     NCName
> 
> 
> But in TMQL the "Prefix" and ":" are never optional for TMQL-QNames.

That is right, but I will have to look at this whether this is a
problem.  If the prefix is missing, then it is 'just' an item
identifier. Maybe the presentation is just skewed.

> >> - [7] iri
> >>   IRIs must be encapsulated by '"'; why?
> [...]
> > There is another issue here: In
> >    http://en.wikipedia.org/wiki/John_Winston_Lennon
> > and
> >   "http://en.wikipedia.org/wiki/John_Winston_Lennon"
> > the first one is an IRI used as subject identifier. This goes done
> > rule [8] and the second one is an atomic value of type anyURI (or
> > whatever that type is). That is rule [7].
> 
> Ah, okay. Then it's a failure in the grammar, because
> 
>     [13] item-reference ::= identifier | qname | iri
> 
> uses the same rule [7] (with the quotes).

Yes, this is _clearly_ wrong. Will have to fix that.

> >>   IMO this rule should be moved to a "QName" rule
> 
> > You mean that he rules
> 
> >     qname -> prefix identifier
> >     ....
> 
> > should be seperated from the atoms a bit and the explanatory text be
> > put underneath?
> 
> Yes, I think the qname rules are a bit underrepresented.

Will be fixed. Also in the light of the above.

> >> 4.4 Navigation
> >> --------------
> >> - [15] axis
> >>   Several axis use a terminology (i.e. "classes") which is not 
> >>   aligned to TMDM.
> >>   Consider to align the axes names with the TMDM-terminology
> 
> > Definitely. In fact, I would love to see this whole axes business move
> > into TMDM at some point. It has nothing to do with TMQL, not?
> 
> Sorry, I don't understand what you mean.

This is more standard hygiene. In hindsight, I think that the axes
should be described as part of TMDM. TMDM contains the model, and so
TMDM also should have all the necessary mechanism address objects in
this model (it has) and to climb through instances of the model.  Now
the axes are part of TMQL.

This is in context of the TMQL Issue: Refactorization of Standard-Parts

   http://topicmaps.bond.edu.au/new/tmql/issues.dbk

At the moment TMQL has to carry the weight of specifying things which
could be much better elsewhere.

> >> 4.10 Topic Map Content
> >> ----------------------
> >> Do we need this section at all? How is CTM different from any other
> >> textual content?
> 
> > In that, that this is NOT text. If I write
> 
> > for $p in // person
> > return
> >     """
> >        $p isa terrorist
> >     """
> 
> > TMQL does NOT return text strings which are then parsed by the
> > application into a map. TMQL creates already these TM fragments and
> > merges them together as it goes.
> 
> Hmm.... I am not sure that I've understood this feature. If it returns
> something that represents a topic map instance (however that is
> representented), it has nothing to do with CTM, but with the feature
> to generate topic maps on the fly and to return such a structure.
> 
> If it returns a CTM instance / stream (again: whatever that is): How
> does the TMQL-processor know that it returns CTM? Isn't a datatype
> indicator missing?
> 
> I.e.:
>      for $p in // person
>      return
>      """
>        $p isa terrorist
>      """^^http://www.topicmaps.org/ctm/

Aaahh, I now see where the document may be misleading.

""" .... """ is NOT a string. It is NEVER a string.

   [28] tm-content ::= """ ctm-instance """

And this is as far as the relationship with CTM goes: between the
"""'s is an CTM stream. And a TMQL processor will immediately parse it
- together with embedded TMQL {} segments.

When this is evaluated, the processor will generate the TM items as
per this CTM stream. All these items are then combined (merged) and
form together a map.

If one writes

     for $p in // person
     return
     "
       $p isa terrorist
     "^^http://www.topicmaps.org/ctm/

Then this atom (multiplied by the number of terrorist) will be
returned. Which is also valid, but then the application will have to
take over. But this is exactly what makes a lot of mess.

\rho