Re: clink/ilink direction (Was: anchor awareness)
Subject: Re: clink/ilink direction (Was: anchor awareness)
From: "W. Eliot Kimber" <email@example.com>
Date: Fri, 27 Dec 1996 16:11:06 -0900
From firstname.lastname@example.org Fri Dec 27 18: 12:31 1996
X-Hobby: low-tide clam sexing
X-Mailer: Windows Eudora Pro Version 3.0 (32)
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
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
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).
W. Eliot Kimber (email@example.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"