cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: [RT] XLink [*LONG*] (was Re: XLink)
Date Mon, 18 Dec 2000 14:49:47 GMT
At 13:36 -0700 17/12/00, Timm, Sean wrote:
>Jeremy Quinn [] wrote:
>> What is the XLinkHandler, XLinkConsumer, LinkSerializer combo for?
>I'm under the same impression that Paul is...they're used for the
>command-line interface.
>> When I move to using Cocoon 2, I might want to write an XLink
>> Transformer,
>> to replace the XInclude and XSLT steps, is there some other
>> component of
>> Cocoon 2 already doing something with XLinks or is
>> XLinkConsumer etc. just
>> there to make it easier to write an XLink Transformer?
>Let me preface this by stating that I'm assuming that you want your XLink
>transformed to a specific format of link (ie. HTML, WML, whatever). 

Eventually, yes, though that can be handled by whatever style transform is
appropriate for the browser..

>I've spent a lot of time thinking about XLink and C2, and my problem with an
>Cocoon is great for separating content, logic, and presentation, but it is
>I believe that XLink can solve this problem.  The key is figuring out how to
>marry the concept to Cocoon. 

Totally agreed

>Obviously, in order to be able to control
>linking from a central location, we need to be able to take advantage of

This my my approach too.

>This is where I believe a transformer could come in handy.  We
>could have a LinkbaseTransformer that processes the XML against the
>specified linkbase, and generates new XML with the embedded XLink
>information.  This makes it extremely easy to add and modify links just by
>manipulating your linkbases. 


>This makes a lot of sense to me, and it's easy
>to work into C2.
>The next step is to create format-specific links for these specified XLinks.
>This is where things get a little more ugly.  I hope someone has a brilliant
>idea here, since most of the things I've thought of for this step are
>probably somewhat of a hack.

This is my approach .... "in progress" :)

I am developing a site that consists of a large set of nested "sections",
spread across multiple files (in a largely arbitrary manner).

<document style="theory">
	<linkbase xinclude:href="../linkbases/theory.xml" xinclude:parse="xml"/>
	<section id="theory">
		<link xlink:to="theory.3"/>
		<section id="theory.5">
			<link xlink:to="theory.5.2"/>
			<link xlink:to="theory.5.7"/>
		<link xlink:to="theory.2"/>
		<link xlink:to="theory.4"/>

The <document> XIncludes the shared Linkbase.

The document consists of nested <section>s, either with their content
(<about/><author/><content/><history/><keywords/>) inline, or
referenced to
a different file (or ID within the same file) with a <link

The linkbase looks like this (please excuse the wrapping):

<linkbase id="theory"
	xmlns:xlink="" >
	<map xml:base="">
		<loc xlink:label="ma.theory" xlink:title="Theory" xlink:href="index.xml"/>
		<loc xlink:label="ma.theory.1" xlink:title="Work" xlink:href="index.xml"/>
		<loc xlink:label="ma.theory.1.7" xlink:title="Cyber-Communism"
		<loc xlink:label="ma.theory.1.6" xlink:title="The Hi-Tech Gift Economy"
		<loc xlink:label="ma.theory.1.2" xlink:title="The Digital Economy"



The first StyleSheet, does several jobs,

<1> it chooses one section, according to the id="theory.1.5" URL Param,
"collapsing" all the other <section>s of their content

<2> it "de-references" all of your "arc" type links, matching the
"xlink:to" with the "locator's" xlink:label in the linkbase. Copying any
xlink: attributes from the "locator" to the <link>, and apply any supplied
"xml:base" attribute to the hrefs.

<3> it searches the LinkBase for any 'arc's that have either no
"xlink:from" or an "xlink:from" that is my ID, and places the links in the

I think steps <2> and <3> could be handled by a LinkBase Transformer, plus
any loading of linkbases required.

	<link xlink:type="extended" xlink:role="xlink:external-linkset">
 	<l xlink:type="locator" xlink:href="links.xml"/>

My Stylesheets work nicely, but are SLOW!

An XLinkBase Transformer could also cache any linkbases the user come across.

It would then be up to the designer to choose how to render the xlinks
appropriately. Whether they be single or multiple destinations, whether
they want to show "links to me" as well as "links from me" etc.

Maybe <1> could be handled by an XPointer Transformer :)

Sean, have you seen the XLinkProcessor written by Bruno Dumon and Bert Meykens?
It covers all this ground, I cannot make it work properly so I am just
taking the ideas ;) <>

My feelings are that the main role of a LinkBase Transformer would be

	<1> extracting any arcs with reference to my document,
			both from the document and the linkbase
	<2> de-referencing the arcs (working out the href)

It should be standards compliant ... to be generally useful.

I am still trying to understand some of the subtleties of the XLink Spec,
what are "resources" and "roles" good for? ........

One thing I need to sort out in my own head ..... I have two different
types of links going on:

	<1> Structural - those links that tie together the navigational structure
of the material, these could be "implied" by analysing the linkbase.
	<2> Arbritary - all other links

>I originally thought up most of this in July, and I shared it with Scott
>Boag at that time.  I was planning on taking some time to throw something
>together that might help generate ideas, but, unfortunately, some work
>things took priority, and I've been slammed ever since.  I'd love to be
>involved in working on something like this, though, and I think my schedule
>should (hopefully) be calming down a bit after the middle of January.

It would be great to work together on a spec for this.

Implementation does not look too difficult, we have some great examples to
work with. Maybe one of us could do the Transformer and the other the
Processor, so this can be used across C1 and C2?

this is cool :)

regards Jeremy


   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <>     		 <>
    <phone:+44.[0].20.7737.6831>        <>
View raw message