RE: Arch Doc: New section on embedding links in representations

"Simple, single-ended, single-direction, inline links are not the most
powerful linking paradigm imaginable. But they are very easy to
understand. And they can be authored by individuals (or other agents)
that have no control or even access to the other end point."

The problem here is the statement is not true 
of the example presented.  In what context 
is it true that the author of <a href="#foo" > 
does not control or have access to <a name="foo">?

In the case where no access or control is enabled, 
a simple inline link won't work.  A system that 
has a notion of document type (or NOTATION) and 
of a standard protocol for passing an identifier 
in a form which the handler for that type can 
interpret is needed.  Hyperlinking to external  
sources requires more than the hyperlink itself. 
Thus HTTP, MIME, etc.  HyTime went a bit further 
and described all of the classes of representation 
of an address by the nature of it's resolver (thus, 
an address by named location, offset, and so on).

So the example is short on the understanding that 
a lot of *machinery* for want of a better term is 
hiding the mappings.  That is the reason for the 
success, not the named location representation itself.

I know you know that, but the text is oversimplified. 
Is that what is wanted here?

len

-----Original Message-----
From: Norman Walsh [mailto:Norman.Walsh@sun.com]

Here is my first draft of text for the new section 4.5:

Hyperlinks in Representations

One of the greatest strengths of HTML as a resource representation is
the ability to embed cross references (links) inside it. The
simplicity of <a href="#foo"> as a link to "foo" and <a name="foo"> as
the anchor "foo" are partly (perhaps largely) responsible for the birth
of the hypertext Web as we know it today.

Simple, single-ended, single-direction, inline links are not the most
powerful linking paradigm imaginable. But they are very easy to
understand. And they can be authored by individuals (or other agents)
that have no control or even access to the other end point.

More sophisticated linking mechanisms have been invented for the web.
XPointer allows links to address content that does not have an
explicit, named anchor. XLink allows links to have multiple ends and
to be expressed either inline or in "link bases" stored external to
any or all of the resources identified by the links it contains.

All of the current common linking mechanisms identify resources by URI
and optionally identify portions (or views) of a resource with the
fragment identifier. The almost universal appeal of linking between
resources suggests that:

  Inventors of new representation formats SHOULD provide mechanisms
  for identifying links to other resources. Representation formats based
  on XML SHOULD examine XPointer and XLink for inspiration.

The common need to point into a resource, that is, to identify some
portion of its content (or some view of its content) besides the
entire, monolithic resource suggests that:

  Inventors of new representation formats SHOULD provide mechanisms
  for identifying portions of their format. This can most often be achieved
  by describing the fragment identifier syntax for the media type
  that identifies their resource format. Representation formats based
  on XML may find that it is sufficient to allow authors to identify
  elements by ID.

Received on Monday, 16 June 2003 16:02:45 UTC