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

Thanks Norm.  I think you have an understandable 
writeup, but I'll go on a little further here in case 
my assumptions are challengeable (opportunity for me 
to learn).

In HyTime, as you know, a lot of the complexity of 
the specification (pre Groves) was in specifying a 
separation of link and location (link and anchor) and 
then in specifying anchor types based on the 
resolution strategy given a file of some type 
where the type of file could vary based on characteristics 
such as the degree of structure, therefore the actual 
means of addressing the location varied.  That's a really loose 
description, but most here know the problems:

1.  There may be no anchors. 
2.  The given structure isn't predictable or known so 
    the anchor type isn't known.
3.  The author of the link may not have write access so no 
    anchors can be created inline.
4.  Out of line locators are useful but fragile although 
    in principal, a 404 is still workable.

In the face of such problems, the web cut the Gordian knot 
first by linking primarily to one application language type 
(HTML), using indirection for a limited set of image types
and then to XML where all of the typical linking 
strategies are well known.   It is in the face of such 
things as images that one has to resort to an anchor type 
and the handler of that type must either make known it's 
preferred means, typically, named locations.  Writing the 
link does require some information about the endpoint
even if as simple as the name of the location (eg, the 
fragmentID) or the name or the thing that knows the 
name of the location (the resolver for an indirect address).

In practice, there should be a limited set of locator 
types which application vendors agree to support for 
non-XML formats. It is easy enough to embed the link 
because that assumes an editable format for which a 
linking production exists.  The difficulty is relying
on the locator and how it is addressed.

len


-----Original Message-----
From: Norman Walsh [mailto:Norman.Walsh@sun.com]
Sent: Monday, June 23, 2003 11:29 AM
To: www-tag@w3.org
Subject: Re: Arch Doc: New section on embedding links in representations



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ "Bullard, Claude L (Len)" <clbullar@ingr.com> was heard to say:
| "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">?

Well, writing the link requires no control over the endpoint. If,
however, the author of the endpoint didn't provide any anchors, that
is a bit of a problem. For XML, it's a problem that can be addressed
with the XPointer Element scheme.

And I suppose "even access" is overstated, I meant "write access" and
I should have said so.

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

I was trying to balance the full complexity of link traversal with the
relative simplicity (and power) of providing linking elements in
representations.

I'll revise it some and repost it shortly.

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@Sun.COM    | Everything we love, no doubt, will pass away,
XML Standards Architect | perhaps tomorrow, perhaps a thousand years
Web Tech. and Standards | hence. Neither it nor our love for it is any
Sun Microsystems, Inc.  | the less valuable for that reason.--John
                        | Passmore
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+9yrTOyltUcwYWjsRAusIAJ9/rlXP8wRR9E+sLvkq+KzdQIJ9jwCfZL/s
DETgT9+f9x0ZlINpNPL7FCM=
=Ugkq
-----END PGP SIGNATURE-----

Received on Monday, 23 June 2003 12:54:58 UTC