Re: anchor awareness (was Re: Richer & richer semantics?)

Eliot writes:
| >So if we say that "anchor" means "what Hytime calls an anchor" 
| >we will probably find it necessary to come up with a term 
| >to describe what "anchor" presently means to many people.  It is 
| >useful to have a term for anchors-the-author-provided-in-case-
| >anyone-wants-to-link-to-them.  
| 
| How about "element with an ID"?

No, because A's NAME isn't an ID in HTML.  It's just a CDATA label.
That's true of HTML 3.2, also, and there will be nothing to stop
people doing the same in XML (and for the same reasons), although
in XML they may also use IDs (production 52).  

| >Now is <a href="http://www.textuality.com/sgml-erb/mprdv.html">foo</a>
| >a Hytime-anchor 
| 
| Which thing are you referring to?  There are two anchors here: the A
| element itself and the object or objects addressed by the value of the HREF
| attribute.  The A element is always an anchor because it is a contextual
| link and therefore one of its own anchors.  [ ... ]

There's only one anchor here, the A element.  The document pointed 
to isn't here.  Steve answers the question I asked:

(Steve:)
| > Now is <a href="http://www.textuality.com/sgml-erb/mprdv.html">foo</a>
| > a Hytime-anchor 
| 
| >  - if Tim's server is down?  
| Yes, because whether the server is up or down does not change the
| HTML-defined semantic that this is a link which is also one of its own
| anchors.  (This question seems a lot like asking whether a falling tree
| makes noise if nobody hears it.  Epistemology, anyone?)

See below for falling trees.

| >  - if Tim removes the document?
| Yes, because no matter where the document may or may not be, the HTML
| semantic remains that this is a link which is also one of its own
| anchors.  (The falling tree problem applies here too.)
| 
| >  - if the URL were misspelled? 
| Yes, because no matter where the address leads or doesn't lead, the HTML
| semantic remains that this is a link which is also one of its own
| anchors.

Understood.  

| Now let's talk about the anchor status of mprdv.html.
[ deleted as understood ]

I understand that thinking about hypertext this way may have utility,
but it is not easy to explain to the uninitiated, and it crosscuts the vulgar
understanding of what an anchor is by making anchorness an epiphenomenon
of link validity rather than a markup construct.  That is, you have
to know something exterior about the possible-anchor, which introduces
the epistemological problem.  And that problem is severe on the Internet. 

Just because link traversal fails, you don't know that
the object pointed to doesn't exist.  The server may be refusing to
let you get to it, or it may be malfunctioning, or it may be incapable
of executing your addressing instructions; it may not provide
accurate error information, either.  In fact, the server may be
operating just fine, but for security reasons, it may make no reply
at all to your (perhaps unauthorized) request for the object addressed.
The criterion "there has to be something at the address," which can work in
a closed system, isn't nearly so useful for the Internet.

I suggest that we'll have a much easier time of it all round if we
accept that the world understands "anchor" as a markup construct,
and qualify Hytime-anchor as "Hytime anchor," or something similar.
Right now, I know what Eliot and Steve mean by "anchor," because
they always speak Hytime.  But I don't know what anyone else means by
"anchor" unless they gloss themselves.  
                                                

In any event, perhaps we ought to figure out what we actually
want to do before worrying about the terminology, so long as we
don't end up talking at cross purposes.

Regards,
    Terry Allen    Fujitsu Software Corp.    tallen@fsc.fujitsu.com
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Received on Monday, 23 December 1996 16:17:06 UTC