Re: FYI: TMQL - New slides

On Sat, Apr 2, 2011 at 12:28 PM, Andrew S. Townley <[email protected]> wrote:
>
> On 2 Apr 2011, at 9:21 AM, Benjamin Bock wrote:
>
>>> [...]
>>> So this would be
>>>
>>> bb / homepage / value(xsd:anyuri)
>>>
>>> compared to TMQL@rho
>>>
>>> bb / homepage
>>>
>>> ??
>>
>> Well, if you're so crazy to store the homepage with a _different_
>> datatype than xsd:anyuri, you'll of course have to convert it upon
>> retrieval.
>> If you store the homepage as xsd:string and want to retrieve it as
>> string, you'd do:
>>
>>  bb / homepage / value
>>
>> . If you left out the "/ value", you'd get an occurrence object (as
>> JTM or XTM fragment or TMAPI object or whatever... depending on the
>> engine.
>>
>> I didn't find where TMQL@rho does the automatic conversion xsd:string
>> to xsd:anyuri, though. What's the heuristics? If value =~
>> /web|homepage|url|uri/href/i ? Can you point me to it? Or can I just
>> assume you're looking for differences where there are none?
>
>
> Wait, you get an "object"?  Doesn't this unnecessarily tie you to the concrete model present in the underlying implementation?  Your response certainly implies this.  If so, doesn't that defeat part of the purpose of having a standardized query language?

If you don't like the name "object" you may as well call it "item" as
it done in Robert's draft. The difference is the _auto_-atomication,
not the atomification itself.

E.g. in Robert's draft, if you do:

    select $p >> characteristics homepage
    where
        $p isa person

you will get the occurrence items, not their values. Go to
http://kill.devc.at/system/files/tmql-2008-07-15.html#SimpleContent
and scroll *up* a tiny bit if you don't believe me.

What do you think how the query engine would return the occurrence
item using Robert's draft?
In TMQL4J, you can chose between JTM, XTM or a TMAPI object.

First, the standard does not dictate which one to use or if any of
these should be available.
Second, this does *not* require the implementation to be based on
TMAPI, it's enough to return empty wrappers which call back to the
TMQL-engine for any information which is not inlined in the object.

> It seems to me from the above that TMQL has become a mechanism for walking the particular implementation *object* graph represented by TMAPI/TMDM.  Even from my limited understanding of TMQL, this seems like a huge step away from Robert's draft which had a unified, underpinning model that was not tied to the TMDM (or any specific language binding or serialization thereof) directly but was based on TMRM and, in particular, the path navigation defined within it.

I hope I could enlighten your limited understanding a bit (-;

> If the new TMQL is really just about walking Java object graphs that happen to relate to the TMDM, then why bother with the abstract syntax at all and just leave it down to "dot" notation for navigation through method calls and be done with it.

It's not and I hope this is obvious now.

Benjamin
_______________________________________________
topicmapmail mailing list
[email protected]
http://www.infoloom.com/mailman/listinfo/topicmapmail