Re: Internet Draft for FIG
Sat, 5 Aug 95 13:27:12 EDT

Larry wrote:
> > Thus, one solution would be to add a FRAGREF attribute to the standard
> > set of HTML3 linking attributes. The FRAGREF attribute's value should
> > be an address, such that the entity representing that address will serve
> > as the "fragment id" for the main addressing attribute of that element.
> This wouldn't be a bad idea. Does anyone want to peek under the HYTIME
> lid while we're at it?

This article might be a longer peek than Larry meant... but it may
be helpful.

HyTime requires more SGML support than most (any?) WWW HTML browsers have.
For example, you have to be able to declare and process entities that
are declared in the document instance.

A brief look at the pointer mechanism used by the Text Encoding Initiative
(see TEI P3) might be more rewarding.

The TEI scheme is slightly more robust in the face of changes to the
document in the case that not all elements have IDs.

Both of these mechanisms (HyTime and TEI pointers) assume a valid SGML
document. All applications processing the pointers must resolve omitted
tags in the same way, for example -- e.g. must agree about whether <P>
is a container or not.

If the Web's linking is to be made more powerful, HyTime is one way to
consider going, but once you're past what you can already do with URLs,
you start getting into shaky ground, partly because of poor documents,
partly because of few HyTime implementations, and partly because the
HyTime standard is still changing: for example, the HyQ language has
just undergone major changes, influenced by DSSSL and the work of James
Cark and others.

You don't have to use HyQ to use HyTime, it's optional. And HyTime now
at least acknowledges the existence of the URL.

Since SoftQuad Panorama supports HyTime, and it's an ISO standard,
the SQ party line is probably more strongly in favour of using HyTime than
I might have implied here. But I think that the TEI have come up with
a syntax that's much easier for non-SGML people to manage. And we
support that in Panormaa too, so it's not that far out of line :-)

The best reference so far is by Steve DeRose and David Durand. I don't
have the book here (at home), but will gladly send a full reference if
anyone wants. It talks about HyTime at great length, but also has a short
chapter on the TEI pointers.

I could also post details of the relevant parts of HyTime and TEI pointers
if anyone wants.

For those following the HyTime literature, see
nameloc point to a named element (like ....//..../..#name)
dataloc point to a given character offset, word, sentence, etc.
treeloc point to a given place in the document's hierarchy
clink contains a link from here to another place
ilink asserts a link between two independent documents
ladder combines several `loc'-style notations to make a single link
e.g. find ID x301, then take the third child of that element,
and then link to the third word in that element.
agregate An agregate link is composed of several smaller ones.
e.g. use this to link to parts of several elements at once.

All except ilink are supported in the freely available verion of Panorama,
if you want to experiment with them. (An ilink asserts that there is a link
between two other documents, usually, and Panorama only shows one document
at a time. Panorama does use ilinks in the Personal Web Files, so you can
look at them there if you like, but you probably need the PRO version to
do much with ilinks).

HyTime does support the use of indirection in links, and this is useful
especially for people with large collections of slowly changing material,
as when a filename changes (say), you don't have to change all the links
to that document, but only the definition of the link.
The mechanism for this, though, is using SGML entities, either declared in
the document or declared in a file that is included in the document.
Current WWW browsers support neither of these mechanisms. But then, they
don't support HyTime either!

I am not sure how HyTime relates to the much-cited Dexter Model, partly
because I don't have a copy of the proceedings of the workshop in which
the paper on Dexter was published. That's no excuse, and I am trying to
order a copy, but in the meantime, please don't ask me to compare the two.
I am happy to try and answer other questions, though :-)