Re: Suggestion: A link model

At 12:19 PM 12/30/96 -0500, David G. Durand wrote:
>At 3:24 PM 12/29/96, W. Eliot Kimber wrote:
>>In HyTime, the anchor roles of a particular link type must be the same for
>>all instances of the type *in the same document.*  This is partly because
>>in the new HyTime design, addressing of anchors is done by attributes whose
>>names correspond to the anchor roles--therefore the anchor role names must
>>be unique within the type and they must be fixed or you couldn't declare
>>the attributes.
>
>    Steve DeRose and I have strongly argued against this mis-feature of
>HyTime many times. It is a pointless restriction that means that one
>_cannot_ define multi-ended links where the number of linkends is defined
>by the application. I thought that this was slated to go away in the TC.
>(At least I hoped there was a chance that someone would want to represent
>pop-up menus as multi-ended links). I strongly urge that we not adopt this
>"feature" of HyTime.

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.  

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

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.

>>Note that we do now have way to indicate that it is *not an error* to for a
>>given anchor role to consist of zero objects (i.e., that you can choose to
>>not address anything for a particular anchor role).  That means that you
>>can make any anchor-addressing attribute optional if it is not an error for
>>that anchor to be null.
>></terminology-domain>
>
>What is the syntax for this? In (uncorrected) HyTime, they are both lists
>of IDs, in 1-1 correspondence, so you cannot "leave one out".

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:

<!-- Edit link: relates source to change and, optionaly, to a comment
                about the edit. -->
<!ELEMENT EditLink   EMPTY >
<!ATTLIST EditLink
          anchrole  CDATA #FIXED "sourcetxt newtxt comment"
          sourcetxt IDREF #REQUIRED
          newtxt    IDREF #REQUIRED
          comment   IDREF #IMPLIED
          emptyanc  CDATA #FIXED "error error ignore"
          HyTime    NAME  #FIXED "hylink"
>

...

<!-- References are to datalocs that address the actual text bits -->
<!-- First example: omitted anchor-addressing attribute: -->
<editlink sourcetxt="dataloc-1"
          newtxt="dataloc-2">

<!-- Second example: Location address that returns empty list: -->
<listloc id=null-list></listloc><!-- Empty listloc returns empty node list -->
<editlink sourcetxt="dataloc-1"
          newtxt="dataloc-2"
          comment=null>

Cheers,

E.
--
W. Eliot Kimber (eliot@isogen.com) 
Senior SGML Consulting Engineer, Highland Consulting
2200 North Lamar Street, Suite 230, Dallas, Texas 75202
+1-214-953-0004 +1-214-953-3152 fax
http://www.isogen.com (work) http://www.drmacro.com (home)
"Rats in the morning, rats in the afternoon...if they don't go away, I'll be
re-educated soon..."                 --Austin Lounge Lizards, "1984 Blues"

Received on Monday, 30 December 1996 13:13:05 UTC