forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject [RT] Adding protocols to links: why?
Date Wed, 11 Dec 2002 07:54:49 GMT
On Tue, Dec 10, 2002 at 12:00:04PM -0800, Stefano Mazzocchi wrote:
...
> BTW, Jeff, don't want to be a pain in the ass, but I would suggest that 
> we move from a URI-based link estimation to an attribute based one. I 
> don't care what attribute and what namespace, but I'm concerned about 
> the fact that this solution is not future-compatible, say, for example, 
> if I have URIs that already contain a protocol, what do I do?

I'll pick on Stefano here to illustrate the thinking behind this patch.

Here is the premise I'm working on:

  Links should be treated as first-class objects, on par with documents.

In particular, that links get transformed: that a _source_ link is
distinct from a _destination_ link.  Just as primer.xml is distinct from
primer.html, so a "link to the Forrest Primer" should be distinct from <a
href="primer.html">.  The _source_ link is semantic; the _destination_
link is HTML.


Traditionally in Forrest, a <link href=".."> is the same as a <a
href="..">.  When you specify <link href="primer.html">, you are
_relying_ on that one-to-one correspondence.  That, IMO, is wrong.  At
the stage of writing XML, 'primer.html' doesn't exist, so why should you
be able to link to it?  And why should you assume that Forrest will
render it to HTML?

We need a linking system that is independent of the output.  We need to
be able to say, "link to the Forrest Primer", and not care if "the
Forrest Primer" is rendered as forrest.html, or ../forrest.html, or
forrest.pdf, or forrest.svg.

So a link to the primer in XML should be <link href="primer">, or <link
href="site:/primer">, or something like that.

So far, I've described "semantic linking" as proposed by various people
in earlier threads.  I hope the need for semantic linking in source XML
is uncontroversial.  Why am I bringing it up now?  Because of an
implication of semantic linking: source link != destination link.  One is
transformed into the other.  So <link href="site:/primer"> in XML is
transformed into <a href="primer.html"> or <fo:basic-link> or whatever.

So to be clear: <link href="file:hello.pdf"> in XML is NOT THE SAME as <a
href="file:hello.pdf"> in a HTML document.  Perhaps it would be better to
use <link href="source:hello.pdf"> to make this clear.

Here is a hypothetical example of a link to a java class: <link
href="java:org.apache.forrest.MyClass">, which gets rendered to <a
href="../../apidocs/org/apache/forrest/MyClass.html">

Another example: <link href="person:JT">, which gets rendered to <a
href="mailto:jefft at apache dot org">Jeff Turner</a>

So there's four examples of Source schemes.  'file:' or 'source:',
'site:', 'java:', 'person:', plus the implied 'cocoon:' scheme in front
of links without a scheme.

Now, does it make sense to specify the type of link into a separate
attribute, like 'role' or 'type'?  No, because the link href specifies a
URI, and a URI has a _scheme_.  What is a scheme?

  "The URI scheme (Section 3.1) defines the namespace of the URI, and
  thus may further restrict the syntax and semantics of identifiers using
  that scheme.
      http://www.ietf.org/rfc/rfc2396.txt

Now isn't that _exactly_ what file:, site:, java:, person: and cocoon:
are?

Summary:

1) Links in xdocs are completely unrelated to links in output files.
2) I think we should evolve Forrest to where _every_ link is a semantic
   link.  The file: scheme is the first stone thrown in this revolution.
   Far from being not future-compatible, I propose that schemes like
   file: _are_ the future :)


--Jeff

Mime
View raw message