Introducing all TMDM data structures would probably add another
type dimension into TMQL.
--
One option we have is to treat this as "language pragma"
pragma INTERFACE_MODEL (TMDM)
return $t/bn # returns basename item
pragma INTERFACE_MODEL (simple)
return $t/bn # return string
pragma INTERFACE_MODEL (maplet)
return $t # returns topic as part of a maplet
only allowed on the outest level so that it does not affect language
semantics, but only interface semantics.
Or, to choose a reasonable default and use 'ATTRIBUTE'
(meta-information on data):
return $t/bn'TMDM # returns basename as item
return $t/bn # default is stringification
return $t/bn'VALUE # same
I am not sure about Toma and AsTMa but in TMPath I have special
'shortcuts' which help to get and return values.
If I need base name node I use:
$topic/bn[<name type>] or just $topic/bn
If I need value I use $topic/bn::<name type> or $topic/bn::*
TMPath provides access and allow to return TMDM constructs.
For example, long path:
$topic/roleOf[who]/association[born-in]/role[where]/topic[city]
goes by all TMDM nodes.
But there are also 'shortcuts' which help to move in 'hyper space'.
$topic/roleOf::who[born-in]/role::where[city]
or $topic/who[born-in]/where[city]
or (with binary projection bornIn for association born-in)
$topic/bornIn[city]
Detailed paths are used typically in questions with introspection.
Shortcuts are used when I know types of names, occurrences, roles and
associations and I am interested in "values".
I think that "full" result sets such as XML, TopicMaps/fragments and
tables can be reasonably easy integrated with host environment.
XML->DOM or SAX
Topicmap -> TMAPI based set of classes
tuple streams -> lists or streams or cursors
I am not so sure about partial results such as list of base names.
Partial results are useful between TMQL layers (TOLOG->TMTL)
But I do not see "standard" way of integration of partial results with
hosting languages.
Dmitry
|
