[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] Dynamic Generation and Serving of Topic Maps
This discussion, and the one between Lars and Chris on the nature of the conceptual model, are in my view very helpful and crucial aids to understanding what we are doing. I would venture to suggest that an appropriately edited rendition of the essence of the things expressed in these exchanges should form part of the text of the introductory part of the XTM 1.0 specification itself. Daniel -----Original Message----- From: Steven R. Newcomb [mailto:srn@coolheads.com] Sent: 03 November 2000 18:17 To: xtm-wg@egroups.com Subject: Re: [xtm-wg] Dynamic Generation and Serving of Topic Maps > From: "Graham Moore" <gdm@stepuk.com> > Date: Fri, 3 Nov 2000 14:39:14 -0000 > I agree strongly with Lars here. > The model that gets built from processing (importing and > holding a representation) a topic map is not a DOM. I, too, would like to underline, emphasize, and shout from the housetops that: In their useful form, topic maps are ALWAYS topic map graphs. They are NEVER topic map documents. (A topic map graph is a set of nodes that represent topics, with interconnections between them, that fully expresses a topic map, and to which a random-access API can be provided. A topic map graph can be implemented in many ways, e.g. as a relational database, as a set of C++ objects in memory, etc.) Let me say this again in a different way. Topic map documents, including XML documents that conform to the XTM Specification, are utterly unreliable tools for every purpose except interchanging and reconstituting topic map graphs. Topic map graphs must be created from topic map documents before the information contained in the topic map documents can be made available for any useful purpose. Let me say this again in a different way. Anyone who thinks that they can use the DOM to gain direct access to the information contained in topic map documents is totally in the dark about the nature of topic maps and about the meaning of the information contained in topic map documents. BEWARE OF THIS GRAVE ERROR. It is based on a false assumption that is pervasive in Web-land, and this is the reason why the error is so very common. The false assumption is that the syntax of an XML document is also always the API to the information that it contains. While that assumption may work for comparatively simple kinds of information, it cannot work for n-dimensional information. Topics are inherently n-dimensional. The connections between topics are inherently n-dimensional. The conections between the connections between the topics are inherently n-dimensional. Etc. Any interchange syntax for topic maps necessarily squashes all these dimensions into a single string. There is not now, nor can there ever be, any practical way for topic map information, which is inherently multidimensional, to be represented as a single string of characters in such a way as to allow applications to skip the step of reconstituting the topic map graph and still understand the information contained in the topic map document. Objection: So, how can we get topic maps onto the web if they have to be interchanged and then wholly processed by their recipients before they can be used? That idea won't scale! Answer: XTM 1.0 won't answer this very good question. XTM 1.0 will provide a syntax for the interchange of topic map graphs, it will describe what a topic map graph is, and it will describe the process by which an interchangeable XML topic map can be reconstituted as a topic map graph. After XTM 1.0 is published, our next task is to describe how to support interactions with remotely-maintained topic map graphs via the Web. Please be patient. We're moving as fast as we can. Your question about how topic maps can be scaled up and accessed remotely will be answered. Just be informed that the remote access to topic map graphs cannot be via the DOM. The DOM provides access to the properties of parsed XML documents, but not to the properties of topic map graphs. -Steve -- Steven R. Newcomb, Consultant srn@coolheads.com voice: +1 972 359 8160 fax: +1 972 359 0270 405 Flagler Court Allen, Texas 75013-2821 USA **************************************************************************** > From: "Graham Moore" <gdm@stepuk.com> > Date: Fri, 3 Nov 2000 14:39:14 -0000 > I agree strongly with Lars here. > The model that gets built from processing (importing and holding a > representation) a topic map is not a DOM. > In order for XPath to perform useful topic map queries on the topic > map serialisation means that the XPath will have to do alot of > hopping around in order to first build the topic map model. I dont > think that this will be pretty. > > On Behalf Of Lars Marius Garshol > > Sent: 03 November 2000 11:56 > > Subject: Re: [xtm-wg] Dynamic Generation and Serving of Topic Maps > > * Dave Pawson > > | > > | Whats missing from XSLT/XPATH for queries, which produce XML > > | results? > > * Murray Altheim > > | > > | Yes, this was my feeling as well. If XPath and XPointer don't fill > > | the bill, then we're in trouble. I'd think "XTMQL" would be simply a > > | document showing how to perform common XTM queries using XPath and > > | XPointer. > > Topic maps and XML have two completely different and unrelated data > > models. Using XPath for topic map queries is going to be terribly > > awkward and not likely to provide the right kinds of functionality at > > all. > > Furthermore, XPath does not support updates or deletions, which TMQL > > probably should. > > | There shouldn't be much need for anything else. If we're talking > > | about query languages for databases, we're no longer talking about > > | querying topic maps as XML documents, which to me seems waaay out of > > | scope for this activity. > > To me it is very difficult to understand how anyone can say this. > > Some topic maps may be XML documents, but that is an entirely > > coincidental and not very interesting fact. I very much doubt that > > any serious topic map applications will be based on topic maps as XML > > documents, but rather on databases. > > Furthermore, to TMQL, the actual form in which the topic map happens > > to be stored should not matter at all. To be honest I'm worried to see > > anyone at all thinking differently. > > > > --Lars M. To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com -------------------------- eGroups Sponsor -------------------------~-~> eLerts It's Easy. It's Fun. Best of All, it's Free! http://click.egroups.com/1/9699/4/_/337252/_/973272924/ ---------------------------------------------------------------------_-> To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC