Re:Can we be more concrete...
Subject: Re:Can we be more concrete...
From: "W. Eliot Kimber" <firstname.lastname@example.org>
Date: Tue, 31 Dec 1996 09:06:03 -0900
From email@example.com Tue Dec 31 11: 08:03 1996
X-Hobby: low-tide clam sexing
X-Mailer: Windows Eudora Pro Version 3.0 (32)
At 03:50 PM 12/31/96 +0000, Digitome Ltd. wrote:
>etc. Should we not be building on this existing terminology base
>rather than invent a new one? This, after all, is the terminology of
>the target market. If this was done could we maintain a link (sorry)
>to the "correct" HyTime terminology and include it in an appendix?
As I said in an earlier post, even if the final XML design is HyTime
conforming, it's not necessary to expose that in the base spec--thus
there's no direct requirement to use HyTime terminology in the spec. It
will be necessary to provide the mapping from XML terms to HyTime terms at
some point, either as an appendix to the spec or as a separate TR.
I say this because I recognize several realities that constrain the direct
exposure of HyTime in the XML linking spec:
1. There is, for whatever reason, significant hostility to HyTime in general.
Why invite trouble? HyTime, as a standard, is a somewhat different
animal from SGML, in that HyTime is designed, in part, to be retrofitted
to existing document types and applications: it defines semantics more than
syntax, therefore, there's less urgency in building in HyTime from the
(although I still think that's a good thing--but then I would).
2. HyTime, is, by the nature of its scope and generality, complex and
somewhat difficult to understand (although I hope we've improved on
that with the TC). Because what XML needs is relatively simple compared
to the totality of what HyTime (or any other industrial-strength
hypertext scheme) can do, there's no reason to unduly burden the XML
Link spec with complexities it doesn't need. One of the points of
XML is to hide the complexities of the architectures from which it
is derived until you're ready to move beyond XML.
Note that we, as designers of the spec, will have to expose to
ourselves some of these complexities so that we can come to
clear agreement on the simplifications the final spec embodies.
In other words, we have to know how the simplicity and constraints
of XML Link relate to the more general features and concepts of
the specs from which they're derived (whether that's HyTime, TEI,
It's a cliche', but a true one, that only experts can write good
basic texts. Thus, in the process of applying our collective
expertise (which is pretty vast) to the problem of creating a
basic text for XML Link, we'll have to chew on many expert-level
issues, in part to be sure of those we can avoid in the spec.
3. The terminology of hypermedia is, in general, murky, and HyTime
doesn't necessarily help--many of the common terms are overloaded
and not necessarily intuitive to the uniformed observer. Therefore,
we should give greater weight to usability of the spec than to
terminological conformance to one particular standard.
As an aside, there's no point in trying to defend the terminology used in
the HyTime standard: it's there and that's that, for good or ill. But I
think it's important to remember that HyTime was developed over a period of
years during which many of the important concepts and terms of hypertext
were being developed, so that, at the beginning, there were not always
clear precedents for the use of a particular term. In some cases, the
choices were arbitrary, in others, they made sense within the HyTime
system. In some cases they were chosen out of ignorance of alternatives.
This is the way all standards are developed--it's unavoidable given human
nature and human failings.
W. Eliot Kimber (firstname.lastname@example.org)
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"