Re: The DSSSList Digest V3 #48

["W. Eliot Kimber" <eliot@xxxxxxxxxx>]

Let me make something very clear: There is *absolutely no conflict*
between HyTime and XLink or between HyTime and XPointers (or TEI
locators).

This is so for several reasons:

1. XLink (as defined in the March '98 draft) can be defined as an
application of HyTime. This means that any XLink document can be
processed by a HyTime engine that does not have special-purpose XLink
awareness. (Of course, those semantics of XLink that go beyond what
HyTime was able to standardize, such as behavior, will not be provided.)
[This could change if the final draft of the XLink spec makes radical
changes to the March '98 approach, which seems unlikely.]

2. The abstract model of hyperlinks is fundamentally the same for HyTime
and XLink. Thus we can formally define a semantic isomorphism between
the two specifications irrespective of their syntaxes (should the XLink
syntax eventually be defined such that statement 1 is no longer true,
which would be possible, if difficult to do).

3. HyTime allows *any* addressing syntax to be used within a HyTime
context (what HyTime calls "query location addresses"). All that is
required is that the syntax be definable in terms of operations on
groves. There cannot exist a syntax for which this is not possible
(because any kind of data can be given a grove representation).
Therefore, not only is the use of XPointers (or TEI locations) possible
within a HyTime context, *it is highly recommended*. It is recommended
because these are both very convenient syntaxes for doing addressing in
certain use contexts. While HyTime provides *a* syntax for doing
addressing, it does not presume that it is the best syntax for all
situations. HyTime's syntax is optimized for completeness, flexibility,
and indirectness. It is not optimized for compactness nor can it be used
in URLs. Therefore, addressing syntaxes that *are* optimized for
compactness and/or use in URLs are necessary and useful.

So I don't want to hear anything more about "conflicts" or "competition"
between HyTime and other facilities that do linking and addressing in an
SGML/XML context, because there aren't any.

The choice to use XLink/XPointer or HyTime is one you should make based
on best fit for requirements.  XLink/XPointer does an excellent job of
satisfying the requirements of the 80% of users who need less than 20%
of what HyTime offers. HyTime does an excellent job of satisfying the
remaining requirements of the 20% of users who need more than
XLink/XPointer provide.  It's the difference between buying a VW Golf or
a Volvo truck: you don't buy the former to haul goods long distances and
you don't buy the latter to take the kids to soccer.

XLink provides a natural and smooth migration path to a more-functional
HyTime-based solution, such that as you reach the limits of what XLink
provides, you can start adding the HyTime facilities you need without
the need to change your existing data (you will, of course, need to
change your DTDs, but not the instances they govern).  By the same
token, if you implement an XLink engine, you will have already solved
most of the hard problems inherent in building a HyTime engine, such
that moving from XLink-only support to more complete HyTime support is
an incremental effort, not a total re-implementation effort.

And, it is not true that "HyTime has not been widely implemented".
Synex's Viewport engine implements a significant part of HyTime.
Viewport has been widely used and deployed. What *is* true is that the
full feature set of HyTime (or even of the location and linking modules)
has not been widely implemented. But it has been implemented in a
variety of ways and will be more widely implemented very soon.

For example, TechnoTeacher will soon release version 1.0 of their
GroveMinder tool which will include a full-featured HyTime engine (for a
demo, send email to Steve Newcomb, srn@xxxxxxxxxx). My PHyLIS tool
(www.phylis.com) is a reasonably full-featured HyTime engine implemented
in Visual Basic [PHyLIS is an educational toy, not a production-quality
product]. I have personally implemented HyTime functionality for
production use in ADEPT*Command Language, Perl, and DSSSL.

The Topic Map standard, ISO 13250, is a HyTime application that will
soon be supported by a number of commercial products.

Cheers,

E.

Ralph Ferris wrote:

> Date: Sat, 22 May 1999 06:00:27 -0400
> From: Norman Walsh <ndw@xxxxxxxxxx>
> 
> >Personally, I wouldn't characterize XLink and XPointer as
> >"competition" with HyTime, just an alternative. But I agree that
> >HyTime is less likely to be implemented. But HyTime has never
> >been widely implemented.
> 
> >Date: Sat, 22 May 1999 10:31:54 -0400
> >From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
> >
> ><reply>
> >...So, it remains that XLink/XPointer
> >and Hytime are competing for "market share" (i.e. the biggest number of
> >implementations) and mind share (i.e. the biggest number of people knowing
> >these specifications). Actually, Hytime starts with a handicap. A not
> >completed spec is more popular than a mature spec (since several years).
> ></reply>
> 
> Actually, the XLink/XPointer vs HyTime issue is part of a longer standing
> issue: HyTime vs TEI. Years before there was an XML, Steve DeRose and Dave
> Durand wrote "Making Hypermedia Work, A User's Guide to HyTime." This
> "HyTime" book included a section on TEI pointers that made it pretty
> obvious which approach the authors' preferred.


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist