[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@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