Re: Suggestion: A link model

At 11:11 AM 12/30/96, W. Eliot Kimber wrote:
>The HyTime design team obviously disagrees with Steve and David on this
>point (and in fact, is about the only point on which we *do* disagree in
>any fundamental way).  I think we may be seeing a collision of conflicting
>requirements that cannot be satisfied by a single solution.  We think we
>have provided an adequate, general, and consistent solution to the problem
>of representing menus through the use of combinations of hylinks and agglinks.

>>    I expect Eliot to claim that the above is false. I do not believe  that
>>composite anchors (discontinuous selections) are the same as multiple link
>>endpoints, and so I do not accept the proposal that he is likely to make. I
>>also think that _for XML_ this will not work, as I think that discontinuous
>>link endpoints (HyTime (unrevised) multlocs) should not be part of XML.
>>They are a bit too esoteric for our audience, I think.
>
>I disagree that multiple locations should not be a part of XML--I think
>they are a significant value add, being one of the things that will
>distinguish XML linking from HTML linking.

I like them too, but the case is not as strong as it is for ilink (which
has been spontaneously proposed many times in WWW contexts). Aggregate link
endpoints are not nearly as popular, so I think we could leave them out.
They also present display problems, particularly for the rather retarded
user-interface models typical of current browsers.

>It's also possible that we have a terminology conflict here.  In HyTime,
>"multiple link endpoints" requires that you have multiple anchor roles, one
>for each link end.  Allowing variable numbers of link ends means requiring
>variable anchor roles *AND* (here's the catch) requires that a unique
>anchor role be specified for each distinct link end.

I don't see any terminology problem here. I just disagree that anchor roles
have to be fixed.

> Our reasoning is that
>the analysis of the roles within a link type is best done at the time the
>type is declared.  It would, we think, be undully onorous to require
>authors to make up (probably arbitrary) anchor role names when all they
>want to do is add to the list of things linked.

It's unduly onerous to require a static type declaration when they do not
have a fixed set of linktypes and roles. Strong typing is useful, but not
everyone wants it. If you don't want it, how can you turn it off?

> Thus, we provide the
>agglink form which lets you relate an unlimited number of things together
>without first defining a distinct role name for each.

What if I want to dfine distinct role names for each, but not in advance?
That is the feature request, and blusterung about link types does not
change the answer that you are giving "No, because _we believe_ that it is
not what yolu really want."

>We also feel, obviously, that the anchor roles are a *constant* property of
>a link type--if you want a different set or number of roles, it's a new
>type, so declare a new type (which, by the way, XML makes pretty easy since
>you can omit the formal declaration altogether if you want to).  Or, create
>a new document in which the same type has a different definition.

    So, HyTime is incapable of representing a hypertext system that does
not limit link types to a static list. This is not a limitation that we
should take over into XML. It is not a limitation that has been justified
either. I am _not_ questioning that strong linktypes can be useful, just
that they must be mandatory for what is supposed to be an inclusive
standard (HyTime).

   And the equivalent information (rev and rel) in HTML is not strictly
controlled in the way that you are asking. Nor are the HTTP Link: header
values. These might be relevant hypertext functions that XML would wish to
subsume!

>Not any more.  Please review my summary of TC changes: the new syntax for
>hyperlinks is that there is one attribute per anchor role, the so-called
>"anchor-addressing attributes".  We have also clarified that it is possible
>for most location address elements to address empty lists.  This provides
>at least two ways for an anchor to fail to address anything: either by
>simply omitting the anchor-addressing attribute or using a location address
>that returns an empty node list.  Here are examples of both:

This is truly unfortunate. The original design was susceptible of
improvement, this one is not. XML should define a mechanism for assigning
anchroles to the endpoints of an agglink, in that case, and maybe the
HyTime committee will see fit to include it.

In fact, I think the solution I proposed will still work, but just won't be
HyTime compatible any more, since HyTime is too inflexible to accomodate
it. Can we make agglink equivalents of both clinks and ilinks?

  -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Monday, 30 December 1996 15:03:57 UTC