Re: [topicmaps-comment] TMs & XTM [Was: skills to create topic maps]

[Murray Altheim <murray.altheim@sun.com>]

Sam Hunting wrote:
> 
> > > This magical piece of software is necessary for XTM conformance
> > > testing. It would normalize the output of XTM processors and make
> > > them line-by-line compareable.
> 
> I'm not sure if "comparability" needs to be defined as "line for line"
> comparability. In particular, I don't see why the preservation of
> insignificant white space is required for comparability. The prospect
> of having to maintain all whitespace across multiple merges,
> particularly in the case of the humongous topic maps that will result
> if topic maps are the success that we all hope they are, seems like a
> lot of overhead for no gain. The sooner the topic map community decides
> that making the processing of topic map documents dependent on white
> space is bad practice, the better.

Where in the heck did you get whitespace as the issue? Even diff
itself has a -b option to ignore whitespace. What I believe would
be the normalization requirements would be to express specific
semantic components in the same way on export, make specific decisions
on the types of merges and reified topics to express (eg., how to 
deal with XTM 1.0 PSIs, the sorting order within the topic map itself
as well as the children within each element, how to express topic
references, base name variants and other things in a logical order, etc.

> >   3. graph normalized
> >      This would be a topic map that throws XTM interoperability
> 
> What? IMHO, if two topic map documents produce the same graph, they're
> the same topic map, ie interoperable. That is the whole purpose of
> *having* the graph. What that is meaningful is thrown to the wind?

What you consider meaningful and what others might may be two different
things. All XTM syntactical expression is lost in transference to the
topic map graph, eg., how an instance-of relation is expressed is lost,
and the syntactic complexity is reduced markedly in exchange for a 
verbose graph structure. Going *back* to XTM from this graph will be
a very interesting problem to solve, unless there are rules for 
reconstituting each expression. 

If Ontopia decides to re-express each instance-of using <instanceOf> 
and Mondeca decides to use an <association>, they're both technically
correct, but "interoperability" is lost. Perhaps a better word is in 
order. "Author intention" is what I've previously called it, ie., 
fidelity to the original XTM syntax, such that an author processing
an XTM document wouldn't be entirely shocked to see what a simple
import-export cycle did to their document.

#2 would be specification for that re-expression, whereas #3 is the
expression in the verbose non-XTM graph syntax, as I've said, similar
to Steve and Michel's graph DTD. No offense, but kinda ugly and dumb
and extremely verbose, but canonical and very useful in a way that XTM
cannot be. It'd be the only standardized way to express in XML syntax 
that final graph, all nodes and arcs.
 
Murray

...........................................................................
Murray Altheim                         <mailto:murray.altheim&#x40;sun.com>
XML Technology Center, Java and XML Software
Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025

               Rally against the evils of iceburg lettuce! 
            Grab a kitchen knife and join the Balsamic Jihad!