Re: Richer & richer semantics?

At 04:56 PM 12/20/96 -0800, Tim Bray wrote:
>I think we all agree that enriched hyperlink semantics are A Good Thing...
>the question is, what are the trade-offs?  It is a basic requirement that 
>anything we put into this be (a) tractable to implement and (b) easy to 
>explain.  It's not clear to me that a solution based on groves/grove-plans, 
>or a query language, meets this requirement.  It's also not clear that it 
>doesn't, but this is a challenge that must be answered.

Tim's point is an important one.  I've been focusing on groves in my recent
discussions because I feel that *as a designer*, groves provide an
essential and useful design formalism that makes it possible to talk about
many previously-murky issues with a great deal more clarity (of which the
DSSSL/HyTime rationalization is evidence).

But it's not necessarily necessary to describe the final design in grove
terms, even if *we* know that it *can be* defined in those terms, just as
XML users don't have to know about SGML declarations even though we know
that there is an SGML declaration that defines what XML needs [mostly].

Here is a note I added to the HyTime standard as part of the grove
information therein:

"Note: The grove formalism used by HyTime is needed for definitional
purposes but need not be exposed to users and document authors under normal
circumstances. The location addressing mechanisms have been designed so
that their default behavior will almost always be what an author would
intuitively expect."

In other words, while we may need to use groves in discussing the design of
XML-specific addressing, we need not expose it in the XML spec if it
doesn't otherwise require it.  

If we say "XML recognizes exactly one way to view XML documents for the
purposes of addressing" then there's no need to expose groves because you
don't need to talk about different abstractions of documents (which is what
groves provide).  On the other hand, if we determine that it's a
requirement to define ways that the same addressing mechanism can be
applied to different abstract views of the same data, then we need groves.

One of the purposes of XML is to define a set of severe constraints that
enable the hiding of complexities required by more general facilities.
This is a good thing as far as it goes and I whole-heartedly support the
application of that principle to the discussion of XML linking.

There's nothing we can do in the definition of an XML-specific linking and
addressing scheme that can prevent or impede the application of full HyTime
to XML documents.  It would be preferable, I think, to define the
XML-specific stuff in such a way that it is directly and cleanly definable
as an application of HyTime, but I don't think we need to or should expose
all the richness of function and attendant complexity of HyTime.  We can
certainly include a pointer to HyTime, just as we do to SGML, to say "if
you want to do more sophisticate things, here's a way".

The basic aspects of HyTime, as for SGML, are very simple and
understandable by anyone willing to spend a few minutes to learn them.
They are simple ideas and simple constructs that can be combined in very
powerful ways.  They are based on fundamental ideas of hypertext that
predate HyTime by at least 20 years.

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 Saturday, 21 December 1996 10:13:16 UTC