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: [topicmaps-comment] TMs & XTM [Was: skills to create topic maps]


"Steven R. Newcomb" wrote:
[...]
> Topic Maps are essentially graphs.  There can be any
> number of syntaxes for interchanging these graphs.
> 
> The XTM 1.0 syntax is a really good syntax for
> interchanging topic map graphs: redundancy is
> minimized, and human readers of the XML instances can
> understand the topic maps that are represented by them
> pretty intuitively.  The XTM 1.0 syntax is also *very*
> good for introductory learning about what topic maps
> are and how they work.  For these reasons, and others,
> I believe the XTM 1.0 syntax is the best choice for the
> standardized interchange of topic maps.  It's a "market
> opening" syntax, and (thanks be to God) it's powerful
> enough to keep on working well for the foreseeable
> future.
> 
> It is impossible to design a syntax that meets *all*
> requirements; requirements conflict with one another.
> The requirement that redundancy be minimized is a
> perfectly valid requirement for interchange syntaxes,
> and XTM 1.0 respects this requirement.  XTM 1.0
> therefore does *not* meet the requirement that Tony
> implies in his comment, above, namely that DOM
> implementations be able to be used directly to gain
> access to the topic map graph.  For Tony and others
> like him, the good news is that it *is* possible to
> interchange topic maps by means of an XML syntax that
> accurately and directly reflects the topic map graph,
> so that DOM implementations can directly use the topic
> map without needing a Topic Map engine to translate the
> XML.  In other words, topic maps can be published in
> XML in a way that obviates the need for a topic map
> engine.  There's a price, though: the XML instances are
> necessarily chockfull of redundant information, and the
> tasks of creating and maintaining such instances cannot
> be accomplished by hand.  (The smallest tweak is very
> likely to render the instance inconsistent with
> itself.)
> 
> A syntax for Topic Maps that can meet Tony's
> requirement can be found at
> http://www.topicmaps.net/TMGraphAPI3.htm.  It's very
> redundant, but something like it could be used in the
> way that Tony wants.

IOW, a tool that could import and export XTM syntax for purposes of
authoring, but could also export TMGraphAPI-compliant documents (though
probably not stress importing) would allow interoperability, as well
as Web-based publishing of the product. The only real downside is that
we now need a new processor/interpretor for TMGraphAPI. Do you think
there's any way to express TMGraphAPI documents in XTM? The suggestion
sounds a bit *weird* I realize, but if you thought so we could attend 
to this idea in the PubSubs TC, developing a set of PSIs and Best 
Practices/documentation on how to generate and interpret such documents.

Myself, I'd prefer not having to deal with a second syntax, but would
rather add a layer of semantics on top of XTM if at all possible. 

Murray

...........................................................................
Murray Altheim, SGML/XML Grease Monkey  <mailto:murray.altheim&#64;sun.com>
Java and XML Software
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

       Ernst Martin comments in 1949, "A certain degree of noise in 
       writing is required for confidence. Without such noise, the 
       writer would not know whether the type was actually printing 
       or not, so he would lose control."


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


Powered by eList eXpress LLC