OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xtm-wg] ANN: XTM 1.0 base Perl package (v0.22)


Sam Hunting wrote:
> Great news, thanks. Can you tell me the following statement, true for
> the earlier release, is true for this release:
> 
>    The 'mergeMap' has been implemented but is regarded as
>    deprecated in favour of topic map algebraic expressions.
> 
> and if it is, why this is so? (Normally, standards or specifications
> bodies "deprecate", not individuals...

Well, if I set up guidelines for 150+ topic map authors then I
claim myself the right to 'deprecate' specific uses of a particular
technology. In the same way a software company doing real-time projects
will have good reasons to _deprecate_ the use of object-oriented 
programming.

While there will a more elaborate explanation of this on paper, in short
I do not fancy the asymmetry of the mergeMap construct. My whole idea
about TM merging is based on building expressions like

 ( map_a [ map_i ] map_b ) [ map_k ] map_c

These maps can have placeholders (variables) as outlined by various
TMQL approaches, so that the expression can be automatically also 
a query. (Conceptually, I try to avoid distinctions between a map
 and a map query.)

mergeMap is something like an low-level '#include' in C. It can be 
useful in some special circumstances, but I would prefer to have 
it explicit.

One aspect here is TNC which is useful is some case, but maybe not
in others. The expression syntax allows me to define this explicitely,
a mergeMap does not without fiddling around with syntax.

One other complication stems from the fact, that the maps here can be
distributed. Having a mergeMap of 

   xlink:href="http://some.server.com/where/is/map.xtm"

make sense globally, merging

   file:subdir/map.xtm

does not really have a meaning in a distributed world. Having this
information explicit in an expression lets the user exert some control
using the context he/she is currently in. If this is hidden in a map, 
ugly surprises can happen (and already have happened).

And for operational reasons I _want_ to allow relative URIs everywhere.

\rho

------------------------ Yahoo! Groups Sponsor ---------------------~-~>
Make good on the promise you made at graduation to keep
in touch. Classmates.com has over 14 million registered
high school alumni--chances are you'll find your friends!
http://us.click.yahoo.com/l3joGB/DMUCAA/4ihDAA/2n6YlB/TM
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC