[RT] Adding protocols to links: why?

[Jeff Turner <je...@apache.org>]

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

Re: [RT] Adding protocols to links: why?

["J.Pietschmann" <j3...@yahoo.de>]

Steven Noels wrote:
> A SchemeResolutionTransformer perhaps?
It will have to be aware of the target format. Will this be
passed together with the input data, or will it be determined
by a sitemap parameter? In the letter case, you'll have to
places where the target format matters:
- the style sheet
- the link resolution transformer.
The syntax should be choosen in a way that a mismatch between
the link resolution target format and the XSLT result (or
the serializer) is pretty obvious.

Another concern: usually one XML source file iss mapped onto
one HTML document, but often several XML source files are
mapped into one PDF document. There may be still several PDF
documents generated. You'll need a convention whether a
certain link maps into an external or an internal PDF link.

J.Pietschmann

Re: [RT] Adding protocols to links: why?

[Steven Noels <st...@outerthought.org>]

J.Pietschmann wrote:

> Nice try. If you want to use XSLT for mapping the semantic link
> to a concrete link for the target format, you'll basically have
> to parse an URL, something which is not exactly the primary
> strength of XSLT.
> A possible approach could be a separate map, hand edited and/or
> generated with some other tool (does somebody smell topic maps?)

Yucky ;-)

I'm not aiming at XSLT for this. A SchemeResolutionTransformer perhaps?

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0103539/
stevenn at outerthought.org                stevenn at apache.org

Re: [RT] Adding protocols to links: why?

["J.Pietschmann" <j3...@yahoo.de>]

Steven Noels wrote:
> I don't like having to specify an attribute to indicate what type of 
> resource is at the end of my arc - uri syntax should scale enough to put 
> that all in one identifier.

Nice try. If you want to use XSLT for mapping the semantic link
to a concrete link for the target format, you'll basically have
to parse an URL, something which is not exactly the primary
strength of XSLT.
A possible approach could be a separate map, hand edited and/or
generated with some other tool (does somebody smell topic maps?)

J.Pietschmann

Re: [RT] Adding protocols to links: why?

[Steven Noels <st...@outerthought.org>]

Jeff Turner wrote:

> 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 :)

I like.

I don't like having to specify an attribute to indicate what type of 
resource is at the end of my arc - uri syntax should scale enough to put 
that all in one identifier.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0103539/
stevenn at outerthought.org                stevenn at apache.org