Re: HyTime compatibility (was Re: HTML spec)

Chris Adie <cja@castle.edinburgh.ac.uk>
Via: uk.ac.edinburgh.castle; Tue, 22 Jun 1993 11:13:34 +0100
To: dale@ora.com
Subject: Re: HyTime compatibility (was Re: HTML spec)
From: Chris Adie <cja@castle.edinburgh.ac.uk>
Reply-To: C.J.Adie@edinburgh.ac.uk
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, www-talk@nxoc01.cern.ch
Date: Tue, 22 Jun 93 11:13:18 WET DST
Message-id: <9306221113.ab13569@castle.ed.ac.uk>
Dale Dougherty writes:
> 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. 

From my limited understanding of HyTime, I believe this is correct - 
there is no way you could take a document from one HyTime system and
expect to import it into another HyTime system without change.  But the
task is much _easier_ if both systems are HyTime compliant.

Let's summarise the advantages and disadvantages of adding HyTime CLINKs
to HTML+.

Advantage:

 * Easier to import information from other HyTime-compliant systems, or
   from systems which export information in HyTime-compliant format (of
   which there are currently none).

Disadvantages:

 * Two alternative ways of doing the same thing leads to lack of
   clarity in the DTD.

 * Added complexity in browser code (which would have to support both
   styles of link, and wouldn't have a HyTime engine to help - yet).

On this one it seems to me that the disadvantages outweigh the advantages -
HyTime CLINKs are not the way to go for HTML+.

However, Dale also says:

> there are some challenging ideas in [HyTime] that go way beyond linking.

Could the ideas in HyTime's measurement module and the concept of a FCS
help in defining hot spots within an image?  There would be no
disadvantages associated with multiple ways of doing things.

I'd also like to explore how HyTime constructs could be used to express
synchronisation relationships between documents.

On one or two things I want to take issue with Dale:

> 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.

Did you reject HyTime simply based on these reasons, or were there
specific technical issues which you objected to? If so, I'm interested
to know what they were.

The Davenport Group certainly went on to use HyTime in their SOFABED
spec.

> However, we should not ignore the absence of HyTime-based technology --
> none was developed to test the specification as part of the
> standardization process. 

HyTime-based technology _is_ being developed.

HTML+ will need testing and changing before it is finished.  We should
not be afraid to add bits of HyTime to HTML+ if it looks sensible to do so.
If it doesn't work, it can be replaced.

Chris Adie                                   Phone:  +44 31 650 3363
Edinburgh University Computing Service       Fax:    +44 31 662 4809
University Library, George Square            Email:  C.J.Adie@edinburgh.ac.uk
Edinburgh EH8 9LJ, United Kingdom