A document has been updated:
http://cocoon.zones.apache.org/daisy/documentation/1102.html
Document ID: 1102
Branch: main
Language: default
Name: LinkRewriterTransformer (unchanged)
Document Type: Sitemap Component (unchanged)
Updated on: 9/10/08 11:33:25 AM
Updated by: David Legg
A new version has been created, state: draft
Parts
=====
Long description
----------------
This part has been updated.
Mime type: text/xml (unchanged)
File name: (unchanged)
Size: 7916 bytes (previous version: 8361 bytes)
Content diff:
<html>
<body>
--- <p>The LinkRewriterTransformer is an extremely useful transformer that can
play
--- a large role in how resources can link to other resources.</p>
+++ <p>The LinkRewriterTransformer can help in situations where one resource
needs
+++ to link to another resource but without needing to know in advance the final
+++ destination of that second resource.</p>
--- <p>It takes some XML at its input, searches for certain specified
attributes of
--- nodes and changes their value according to some pattern before passing the
--- resulting XML onward through the pipeline.</p>
---
<p>The transformer was originally developed as part of the Apache Forrest
--- project. In earlier versions of Forrest (and in similar systems), there was
--- only one URI space: that of the generated site. If page1.xml needed to
link to
--- page2.xml then page1.xml would use:</p>
+++ project where there was a need to allow documents to refer to other
documents in
+++ a portable way that didn't break as those documents were moved around or
+++ rendered to different formats. The solution was to give those references a
+++ separate namespace and transform them as necessary when the target's final
+++ address became known. So for example, instead of one document referring to
+++ another like this: <a href="aPage.html"> it could use <a
+++ href="site:aPage"> where:</p>
--- <pre><a href="page2.html">See Page 2</a></pre>
---
--- <p>A problem with this is that the content producer should not know or care
how
--- the source page is rendered. A URI should only <em>identify</em> a
resource,
--- not specify it's type. If for example our page2.xml file was rendered as a
PDF
--- file, you can see that the link in page1.xml would break.</p>
---
--- <p>Forrest's solution was simple: instead of <a href="page2.html">,
write
--- <a href="site:page2"> where:</p>
---
--- <blockquote>
--- <p><strong>site</strong> is a URI "scheme"; a namespace that restricts the
--- syntax and semantics of the rest of the URI. The semantics of "site" are
"this
--- identifier locates something in the site's XML sources".</p>
--- </blockquote>
---
--- <blockquote>
--- <p><strong>page2 </strong>identifies the content in page2.xml by reference
to a
--- "node" of content declared in site.xml We call this indirect, or
--- <em>semantic</em> linking because instead of linking to a physical
--- representation (page2.html), we've linked to the "idea" of "the page2
file". It
+++ <p>site is a URI "scheme"; a namespace that restricts the syntax and
semantics
+++ of the rest of the URI. The semantics of "site" are "this identifier locates
+++ something in the site's XML sources". aPage identifies the content in
aPage.xml
+++ by reference to a "node" of content declared in site.xml We call this
indirect,
+++ or <em>semantic</em> linking because instead of linking to a physical
+++ representation (aPage.html), we've linked to the "idea" of "the aPage
file". It
doesn't matter where it physically lives.</p>
--- </blockquote>
<h3><strong>Example</strong></h3>
(153 equal lines skipped)
