- From: W. Eliot Kimber <eliot@isogen.com>
- Date: Fri, 27 Dec 1996 16:11:06 -0900
- To: w3c-sgml-wg@www10.w3.org
At 05:04 PM 12/27/96 -0500, David G. Durand wrote: > A "grove" is just a new name for what everyone else in the world calls >a "parse tree". Not exactly correct: groves are a new name for what everyone else in the world calls a direct graph data structure. It happens that one obvious application of directed graphs is the representation of parse trees, but that's not the only thing groves are used for. Groves are useful because the provide the following features on top of the basic directed graph of nodes concept: 1. Optimization for the representation of parsed SGML documents and things more or less like SGML documents. 2. A clear and convenient semantic distinction between "content" nodes and other nodes (thus the notion that a single grove contains multiple distinct "content trees", thus "grove"). 3. Provides a standardized abstraction mechanism divorced from the implementation issues. Thus, in the XML discussion, groves are useful because they are more complete than ESIS for discussing processing the results of parsing and they provide a common, implementation-independent data structure for discussing location addressing. We can't do either coherently without some sort of common abstraction. Groves exist. Ergo, why not use groves in our discussions? Now we could avoid parse trees by using byte offsets, but >given that addressing bytes in markup does not usually make sense, we will >need to have the parse tree anyway -- that's what structural addressing is >founded on. As far as I can tell, the details of groves are irrelevant to >XML, unless we decide that we have to explain how XML linking can be >treated as HyTime linking. I don't think they're irrelevant because I don't think you can discuss location addressing in an open environment without something like groves. We had to invent groves to solve exactly that problem in trying to rationalize DSSSL and HyTime. XML will have the same problem and will need the same solution. > Most of the difficulty seems to be understanding the HyTime model and >terminology, not the basic hypertext functionality. I think that HyTime's >tendancy to complicate the simpleis skewing the discussion. HyTime >terminology is a strange mix of de novo terms and new meanings for old >terms. But semantically, an ilink is no more complicated than a record in a >database that contains external keys. And it has the same shortcoming: you >have to "join" the ilink against a relevant document for it to be >meaningful. We need not prespecify the joins that an XML linking engine >should support, but we need to define the mechanisms to enable them. I think I've said more or less the same thing on a number of occasions: the parts of HyTime XML needs are *simple*. We haven't discussed anything for XML that isn't the simplest application of the most basic concepts of hyperlinking, ideas that have been around for going on 30 years and implemented in any number of ways (many lost during the great extinction of 1987 when the Hypercard commet hit and apparently obliterated the memory of most of the research done up to that point). Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues"
Received on Friday, 27 December 1996 18:12:31 UTC