On Fri, Feb 20, 2004 at 02:19:18PM +0100, Rani Pinchuk wrote:
> > 2. Match: [ 42, "Ramsti", <some other node> ]
> > .. ^^ ^^ ^^
> > || || ||
> > number|| ||
> > || ||
> > string map-fragment
> >
> What bothers me is the mix between scalar types and non scalar types
> (topic node in this case).
Yes, we have to be careful not to go overboard with this.
> > I would say the user specifies what he wants and _exactly_ this should
> > be returned. No hidden magic, no tricks and hidden intelligence.
> >
>
> I support this. I would think that one query could be:
>
> select $topic.bn as string ....
>
> which returns a list of baseNameString for each topic $topic (in
> whatever scopes), and:
>
> select $topic.bn as node
>
> which returns the baseName node (including all the nodes inside it) of
> the topic $topic.
I would assume that a
select $topic.bn ...
could be reasonably defaulted to 'string' output.
--
What I am bit sceptical about is to allow _any_ kind of node type in
the result. So, to allow basename and occurrence and this and that
items as described in the TM DM as possible parts of a list
result. Going that path would link TMQL standard-wise VERY STRONGLY to
TMDM and I am not a friend of strong couplings.
One option would be to allow only maps or fragment thereofs and let
TMQL be completely opaque about this. Another (mumble, mumble) would
be to allow topics and assocations only, but this has some
problems....
\rho
|
