Re: Permitting non-indirect links (2 ccs deleted)

At 6:58 AM 1/11/97, Martin Bryan wrote:
>At 15:04 10/1/97 -0500, Steven J. DeRose wrote:

>>It is not always true that links which are not indirected cannot be managed.
>>For *some purposes* it is true; for other just the opposite is true. But the
>>point is that HyTime (and XML) are meant to be inclusive, and it is wrong to
>>impose a particular implementation model on the entire community.
>
>Depends what you mean by "managed". I "manage" a load of links that are
>embedded in documents by running manual checks on them, but I cannot
>efficiently automate the system as I don't get enough information from the
>Web about them. OK I run the standard checking software, but that only tells
>me when an error occurs, not when the data in the file has been changed,
>moved to another site, replaced by a pointer saying that the file can be
>found elsewhere, etc. This is what I want my "data management module" to be
>able to handle in the longer term. I can do this most efficiently with
>indirected links, and least efficiently with the links embedded at random
>points in my data.

OK. the end result of this is that we have both. We are in raging agreement
that indirection is useful. We disagree, but can live with the use of
direction as well as indirection. Next...

>> Do you actually believe it's easier to manage a link that
>>exists in 20 different elements scattered around a document joined only by
>>IDREFs with each rung separately editable and deletable, than to manage one
>>element?
>
>Link management becomes infinitely easier if you construct separate
>identifier components for the site, directory path, filename and fragment
>path and then "build URLs" at the point they are needed by pointing to the
>one location that contains this inforamtion using invariant names assigned
>to these components. If you need convincing of this look at the URL entry
>form in HoTMetal. Why is it that this does not just have a single entry
>point for a "complete" URL.

This is the first time that this point has been clear. Managing "bits of
URLs" has not been clearly espoused before. The potential utility is high,
for those willing to abide with the overhead.

Can't this be done with general entity references?

<a href="http://&base-server;/&rootpath;/&this-subject-path;/&this-doc">

With the appropriate entity declarations, a link like the above gives you a
powerful lot of indirection without any new hyperlink features at all!


>> I would need to see a rather better argument to believe that.
>
>Convinced of the benefits yet? Now the big question is, can we do this using
>HyTime? I wish I knew the answer to that one!

I'm convinced that it could be useful. We might even already have it!

HyTime location ladders can specify this, and I think that the use of
relative URLs, along with the location facilities we have been talking
about, would actually let you do the equivalent with links.

If you have a location element that specifies a locsrc of
"http://gimp-server.dgd.com/" and a location of "/local-directory-path/"
you should get what you want.

But I am not sure if locsrc will be worth it just for this, especially
since you can use entities to cut-and-paste URLs directly. Locsrc adds
another very genralized source of indirection, and if ilinks scare some
people, locsrcs might. On the other hand, some variation of locsrc is the
easiest way for us to implement the BASE attribute, so we may actually have
two ways for you to do what you want.

>>If I recall correctly, I was not claiming that indirection was evil and
>>should be destroyed. Merely the far less draconian claim that *direct* links
>>can also be useful, and in *some* cases have substantial advantages. Are you
>>prepared to claim that your data is the *only* kind anyone should ever have?
>
>No more than I am claiming that embedded links are not useful. I'm simply
>arguing that there are advantages in allowing both approaches
>simultaneously, and am arguing strongly that the more complicated case
>should not be swamped by the KISS brigade.

So we have a raging agreement. How are the above starts at solving your
problems?

  -- 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, 13 January 1997 11:49:35 UTC