cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <bruno.du...@kh.khbo.be>
Subject Re: XLink Processor for Cocoon
Date Fri, 19 May 2000 18:41:49 GMT
Quoting Donald Ball <balld@webslingerZ.com>:

[...]
> 
> Right - which is all I thought, from a cursory inspection, that your
> processor did (process embedded links). Do you have a notion on whether
> or
> not it's preferable to use XLinks or XIncludes to include fragments of
> other documents?

IMHO, use XIncludes for this.

> What else does your XLink processor do - I must have
> missed the point.
> 

I didn't tell very much about this in my first mail.

Here is a step-by-step description of what the XLink processor exactly does:

1. It scans the current document for XLink descriptions.  All links which are 
found are stored in a so-called 'linkbase' (a database with links) in the 
session object. For Simple XLinks this is straightforward. For Extended XLinks, 
this depends on the presence of arcs. Take for example the following:

<x xlink:type="extended">
  <y xlink:type="locator" xlink:href="file1.xml" xlink:role="a"/>
  <y xlink:type="locator" xlink:href="file2.xml" xlink:role="a"/>
  <y xlink:type="locator" xlink:href="file3.xml" xlink:role="b"/>

  <y xlink:type="arc" xlink:from="a" xlink:to="b"/>
</x>

This Extended XLink actually defines the following 'simple' links:
file1.xml --> file3.xml
file2.xml --> file3.xml

If there are no arc-type elements, links are created between each and every 
other document. All these links are added to the linkbase in the session object.

2. Then the XLink processor looks in the linkbase which links start from the 
current document, and merges these back into the document as Simple XLinks.

Note: the whole reason why it's done this way is because it's possible to 
describe a link in document A which starts in document B and ends in document C. 
When document A is being processed, we get to know that there should be a link 
between document B and C, but we can't do anything with this link at that time. 
Therefore, it's stored in the linkbase, so that when the user requests document 
B, it will be merged into it.

3. The conversion of these Simple XLinks (which were created in the previous 
step) to HTML links is left up to an XSL stylesheet.


As you can see, nothing special is done with XLink attributes like show and 
actuate. It's left up to an XSL stylesheet to do something with them.

(I havn't mentioned everything here: the processor will also read external 
linkbases, supports XPointers for a large part, and probably some other things 
which I can't remember right now)

Hint: if you want to see the contents of the linkbase, you can add the URL query 
parameter "linktable" to the URL of a file which will be processed by the XLink 
processor.
For example: http://localhost/xlinkdemos/index.xml?linktable=true

I hope this can clear up some things for you.

BTW, thanks for all the positive comments on this list.

Bruno Dumon.

Mime
View raw message