You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bruno Dumon <br...@kh.khbo.be> on 2000/05/17 10:18:16 UTC
XLink Processor for Cocoon
Hi,
We are students, and as part of our final project, we have developed an XLink
processor for Cocoon.
What it actually does is interpreting the XLink descriptions which are present
in a XML file and it converts them to simple XLinks, which can then be converted
to HTML links using an XSLT stylesheet. It may sound simple, but since with
XLink it's possible to describe a link in document A wich actually starts from
document B, it's necessary to remember these links. There's also some support
for XPointer.
For those who would like to take a look at it, we've made it available at:
http://bewoner.dma.be/bruno2/xlinkstuff.tgz
It comes with some small demos illustrating the possibilities. Please see the
README file in the package for installation instructions. The program is (of
course) just a 'proof of concept', it's not very well tested.
Greetings,
Bruno Dumon and Bert Meykens
Re: XLink Processor for Cocoon
Posted by Bruno Dumon <br...@kh.khbo.be>.
On Wed, 17 May 2000, Stefano Mazzocchi wrote:
> Great!!! I was going to write something like this... now I can
> steal^H^H^H^H^H borrow it. :)
>
> (if it's ok with you guys, of course)
>
> --
Sure, consider it public domain.
Bruno Dumon.
Re: XLink Processor for Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Bruno Dumon wrote:
>
> Hi,
>
> We are students, and as part of our final project, we have developed an XLink
> processor for Cocoon.
> What it actually does is interpreting the XLink descriptions which are present
> in a XML file and it converts them to simple XLinks, which can then be converted
> to HTML links using an XSLT stylesheet. It may sound simple, but since with
> XLink it's possible to describe a link in document A wich actually starts from
> document B, it's necessary to remember these links. There's also some support
> for XPointer.
>
> For those who would like to take a look at it, we've made it available at:
>
> http://bewoner.dma.be/bruno2/xlinkstuff.tgz
>
> It comes with some small demos illustrating the possibilities. Please see the
> README file in the package for installation instructions. The program is (of
> course) just a 'proof of concept', it's not very well tested.
>
> Greetings,
>
> Bruno Dumon and Bert Meykens
Great!!! I was going to write something like this... now I can
steal^H^H^H^H^H borrow it. :)
(if it's ok with you guys, of course)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: XLink Processor for Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Bruno Dumon wrote:
>
> On Wed, 17 May 2000, Donald Ball wrote:
>
> > Hey, that's not bad at all! Would you care to comment on the pros and
> cons
> > of using XLinks v.s. XIncludes?
> >
> > - donald
> >
>
> XInclude is used for including things, XLinks is used for describing links
> between documents. These are two completely different things. However,
> with XLink it's possible to specify that something should be shown
> "embedded", so that it appears to be included.
In case you haven't noticed, the "embedded" behavior of XLink was
removed in the latest WD because it overlapped with the XInclude idea.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: XLink Processor for Cocoon
Posted by Bruno Dumon <br...@kh.khbo.be>.
Quoting Donald Ball <ba...@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.
Re: XLink Processor for Cocoon
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 18 May 2000, Bruno Dumon wrote:
> On Wed, 17 May 2000, Donald Ball wrote:
>
> > Hey, that's not bad at all! Would you care to comment on the pros and
> cons
> > of using XLinks v.s. XIncludes?
> >
> > - donald
> >
>
> XInclude is used for including things, XLinks is used for describing links
> between documents. These are two completely different things. However,
> with XLink it's possible to specify that something should be shown
> "embedded", so that it appears to be included.
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? What else does your XLink processor do - I must have
missed the point.
- donald
Re: XLink Processor for Cocoon
Posted by Bruno Dumon <br...@kh.khbo.be>.
On Wed, 17 May 2000, Donald Ball wrote:
> Hey, that's not bad at all! Would you care to comment on the pros and
cons
> of using XLinks v.s. XIncludes?
>
> - donald
>
XInclude is used for including things, XLinks is used for describing links
between documents. These are two completely different things. However,
with XLink it's possible to specify that something should be shown
"embedded", so that it appears to be included.
Bruno Dumon
Re: XLink Processor for Cocoon
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 17 May 2000, Bruno Dumon wrote:
> Hi,
>
> We are students, and as part of our final project, we have developed an XLink
> processor for Cocoon.
> What it actually does is interpreting the XLink descriptions which are present
> in a XML file and it converts them to simple XLinks, which can then be converted
> to HTML links using an XSLT stylesheet. It may sound simple, but since with
> XLink it's possible to describe a link in document A wich actually starts from
> document B, it's necessary to remember these links. There's also some support
> for XPointer.
>
> For those who would like to take a look at it, we've made it available at:
>
> http://bewoner.dma.be/bruno2/xlinkstuff.tgz
>
> It comes with some small demos illustrating the possibilities. Please see the
> README file in the package for installation instructions. The program is (of
> course) just a 'proof of concept', it's not very well tested.
Hey, that's not bad at all! Would you care to comment on the pros and cons
of using XLinks v.s. XIncludes?
- donald
Re: XLink Processor for Cocoon
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 17/5/00 at 10:18 am, bruno.dumon@kh.khbo.be (Bruno Dumon) wrote:
>We are students, and as part of our final project, we have developed an XLink
>processor for Cocoon.
This looks very interesting.
It requires patching and re-compiling Cocoon, for Cocoon to setup Xalan to use namespaces.
Is it possible to compile Cocoon on systems without Java 1.2?
Would it be nice to have this patch turned into a cocoon.properties setting?
Thanks
Jeremy
____________________________________________________________________
Jeremy Quinn media.demon
webSpace Design
<ma...@media.demon.co.uk> <http://www.media.demon.co.uk>
<phone:+44.[0].207.737.6831> <pa...@sms.genie.co.uk>