> But a word of caution. In at least two different places I have read
> that HyTime was designed for the INTERCHANGE of hypermedia data, and
> that it is not necessarily a good choice for an efficient run-time
> hypermedia format. Of course, it may well be that the overhead
> associated with HyTime is small compared with the network overhead for
> multimedia data transfer - but we should be aware of the problem.
I am still exploring what it means to make HTML+ HyTime compliant
or compatible. It is really a matter of conforming to some of the
architectural ideas in HyTime. We don't need to take on board
everything HyTime includes. In some cases we might want to provide
a HyTime compliant alternative when the normal HTML approach is
incompatible with HyTime. There is no pressure to adopt features
that would penalise an efficient run-time hypermedia format.
At its simplest, we could provide support for hypertext references
via entity declarations following the CLINK and NOTLOC model. This
means you could declare all the references at the start of the
document, and then use local names throughout the body of the
document where ever you need a hypertext reference.
With WYSIWYG editors this wouldn't be too much of a pain. The HREF
attribute would remain as now, but there would be an alternative
that assumes local names and which is HyTime compliant.
Much of this involves some extra attributes of interest only when
trying to get another HyTime compliant system to make sense of an
HTML+ document. It wouldn't effect HTML+ browsers significantly.
Other aspects of HyTime can be included as additions to the DTD as
a bridge to the future when HyTime location ladders and finite
coordinate space elements become useful.
Regards,
Dave Raggett