Re: HyTime compatibility (was Re: HTML spec)email@example.com (Dale Dougherty)
From: firstname.lastname@example.org (Dale Dougherty)
Date: Mon, 21 Jun 1993 09:21:35 -0700
In-Reply-To: Dave_Raggett <email@example.com>
"HyTime compatibility (was Re: HTML spec)" (Jun 21, 9:55am)
X-Mailer: Z-Mail (2.1.0 10/1/92)
To: Dave_Raggett <firstname.lastname@example.org>
Subject: Re: HyTime compatibility (was Re: HTML spec)
In my opinion, HyTime is not a useful direction for
WWW at this time. It will require a lot of effort just to
understand, and even more to implement on a basic level. As
part of the Davenport Group, I spent more than a year
investigating HyTime for possible use in Docbook DTD and other
online publishing activities. I did not see broad support
for HyTime, as a standard or as technology. I
decided that HyTime was not something to be used by our
current or next generation of technology. I was also very
frustrated that HyTime exists only on paper, and so anyone
can say anything about it without proving it in practice.
You have to separate out the claims made for HyTime and the technology
or applications required to make use of it. Most people
who talk HyTime do not bother to distinguish between the two
and they tend to trivialize the impact on applications.
Remember, there are no HyTime engines available anywhere
and until there are no one can prove or disprove their claims.
When someone says "HyTime allows you to do ....", probe for
specifics. Ask how it works.
You will also have trouble figuring out whether HyTime is
a standard syntactical representation for hypermedia constructs
or a way of life. If the latter, then you have to
start living that way now, or be lost. (And that's why
most HyTime advocates urge you to accept HyTime now.) If it is just
a standard representation of the kind of things we are already
doing, then the door is always open to use that syntax,
should it emerge as something of value.
HyTime is intended to be an interchange standard, and its
awkward syntax is not meant to be processed in real-time.
If you study the standard, you will find out that for
the most part, its method of standard representation involves
putting a standard "wrapper" around application-specific info.
So, for instance, it allows HyTime apps to identify links
in a standard way, but it does not make the link addressing used in
applications interoperable. In WWW, we use URLs for link addressing
and if we send an HTML document to another
hypermedia application, the tough part to interchange is the URL.
If the target app does not understand URLs, the document is
pretty useless. All HyTime would do is put the URL in
a standard wrapper indicating that the tag contained link information.
We should be aware of HyTime -- there are some challenging
ideas in it that go way beyond linking. However, we should
not ignore the absence of HyTime-based technology -- none was
developed to test the specification as part of the standardization
process. If you take the view that
HyTime offers a standard representation for hypermedia documents,
then we should be able to convert HTML documents into
a form that is HyTime-compliant for the purpose of interchanging
documents with other HyTime-supporting apps,
(which do not yet exist). As long as our focus is
on creating documents to be used in the Web,
we don't need to be encumbered by HyTime syntax, much
less by the HyTime way of thinking. Anyone who feels HyTime
is important is free to manage his information using
HyTime-compliant DTDs and then create HTML versions of
those documents for the Web. We do not need it as a way
to interchange documents among Web browsers and create
interoperable links; we have that
level of standardization right now, and we have something
Digital Media Group, O'Reilly & Associates, Inc.
103A Morris Street, Sebastopol, California 95472
(707) 829-3762 (home office); 1-800-998-9938
UUCP: uunet!ora!dale Internet : email@example.com