I continue to believe that the web will splinter without such a model,
and that it is absolutely critical that HTML's "link model" be easily
portable and non-controversial to implement in all these other formats.
> >HTML linking without making it too complicated, other formats will
> >likely follow suit. Some of the issues that need to be addressed:
>
> Well said. I started a draft on this one time:
>
> Toward Reliable, Interoperable Links
> $Id: link-rpc.html,v 1.1 1995/02/14 22:41:10 connolly Exp $
> http://www.w3.org/hypertext/WWW/People/Connolly/drafts/link-rpc.html
Is there anything there that would cause a problem with our current
"minimal" REL solution ? Is there an easy migration path from simple
REL names that browsers can interpret, to a complex name space where
interesting behavior is swapped around as easily as 'cool locations' ?
Of course I'll look, but sometimes the author is the best person to
answer. Your excerpts follow:
> |But before long, we'll see URL style hyperlinks in TeX, Adobe's PDF,
> |probably MIME external body references, and all sorts of other data
> |formats where the URL is consoumed wholly by machine with no manual
> |intervention.
Absolutely. The URL/URI has to be bulletproof.
> |Another context where URLs are used more and more is the "desktop
> |message bus" -- cut/copy/paste, drag-n-drop and clipboard types on X,
> |Mac, Windows, and NeXTStep patforms. Apple Events, OLE 2, and even
> |local-area and wide-area RPC systems based on CORBA, and DCE.
Yes, it is absolutely essential that we call programs with these various
binding mechanisms, in a way that has the same semantic model across all
platforms and formats.
> |For most applications, it appears that a single "token" or "string
> |with no spaces" is enough. The fact that entire HTML forms queries are
> |encoded in URLs regularly shows that this can be pretty expressive.
Likewise for most applications, the single token is a good enough def'n
for the link.
> |But for other applications, folks are putting linking information
> |outside the single URL token. In the S-HTTP proposal[1] for example,
> |to make a secure link or a secure form submission, you need a DN or
> |distinguished name attribute (and possibly some others) in addition to
> |the URL. In the BRIO[2] system, additional anchor attributes are
> |necessary to support a rich annotation system.
Arbitrary attributes really need to be attached to web objects, with some
standard transformation that specifies what behavior is going to be called.
This is the 'link stylesheet' problem again.
I was thinking of a system, where, if we could agree in HTML to always
use the ACTION= or METHOD= attribute, we could reliably transform tags
into function calls with a convention that would, say, turn:
<A REL=next METHOD=getpage HREF="http://www.bogus.com/nextpage">
into:
getpage (next, http://www.bogus.com/nextpage)
Some set of statements like:
METHOD getpage (REL relvalue, HREF scriptvalue) = [CORBA, OLE, RPC call]
would tell the browser what function to call. Some of these would be
hardwired in the browser itself, but there's a clear extension path,
and it unifies behavior of forms and other tags with a METHOD attribute.
Anytime someone needs an application-specific extension, the METHOD
attribute provides a means to 'call out'.
> |So what if I want to cut-and-paste a secure link? A link to a
> |replicated object? Do I loose all the info except the URL? Bad
> |news. Perhaps the "type" of a link is not just the HREF part of the
> |anchor tag, but the whole tag: HREF, DN, URN, etc.
And the REL of course. Right now you lose this stuff.
> http://www.w3.org/hypertext/WWW/People/Connolly/drafts/citations.html
> ...
> So objects/resources are identicial by definition if their URIs are
> identical.
This is the definition of a name as in Universal Resource Name (i.e. URN).
> Then to talk about what goes over the wire, I tend to talk about
> representations of resources, or "entities" -- these are sequences
> of octets with some associated type information.
Like the method-to-function call correspondence as above
> So I don't know what a "copy of an object" means. I know about
> representations of objects...
Copy has several reasonable semantics, usually stated as "deep copy"
(e.g. entire data structure), "shallow copy" (e.g pointer), "name"
(e.g. completely portable name). Because information systems always
have several levels of binding a name, they need several levels of
"copy". No way around it. Well understood problem.
> A Formalism for Internet Information References
> http://www.w3.org/hypertext/WWW/People/Connolly/drafts/formalism.html
I'll check all this out and get back to you by mail. Maybe we need
an 'incubator' effort for this, off the list.
-- Craig Hubley Business that runs on knowledge Craig Hubley & Associates needs software that runs on the net mailto:craig@hubley.com 416-778-6136 416-778-1965 FAX Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5