You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Timm, Sean" <ST...@mailgo.com> on 2000/12/17 21:36:16 UTC
[RT] XLink [*LONG*] (was Re: XLink)
Jeremy Quinn [mailto:jeremy@media.demon.co.uk] 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.
<snip/>
> 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). If
that's the case, I feel like it's the wrong way to go about it, and I'll
tell you why. :) If that's not the case, then we might be on the same
page...
I've spent a lot of time thinking about XLink and C2, and my problem with an
XLink transformer is that that any transformation of XLinks involves
serializing them into the appropriate format (ie. XML, XHTML, WML,
whatever). It's very output dependant on exactly *how* you want the
resultant links to look and/or behave. Obviously you wouldn't want an XLink
translated into HTML for your cellular phone, and you may even want your
XLink behavior to differ between browsers based on the individual ability of
the browser (since there aren't any browsers that support XLink that I'm
aware of).
Cocoon is great for separating content, logic, and presentation, but it is
lacking flexibility in controlling site "flow" (for lack of a better term).
All links are hard-coded by those who write the XSL to go to a certain
section of the site. If you want to rework the way your site navigation
occurs or want to add or modify a link, you have to modify each XSL.
I believe that XLink can solve this problem. The key is figuring out how to
marry the concept to Cocoon. Obviously, in order to be able to control
linking from a central location, we need to be able to take advantage of
linkbases. 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.
The XLink information only carries meaning as long as it corresponds with
the XML. Once an XML stream has been transformed by XSLT, the resultant
output is often disconnected from the original XML. Therefore, my initial
thought is that the transformation of the embedded XLink information should
be performed through some sort of Xalan extension element mechanism. We'll
lose some of our flexibility going this route, but it will still be there to
some degree. I'm not positive that this would work, but hopefully it will
generate some feedback and ideas.
For example, with the XML as follows (pardon the cheesy example):
<?xml version="1.0"?>
<person>
<name>Joe Blow</name>
</person>
And the following XSL:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/XSL/Transform/1.0"
xmlns:xlinkext="org.apache.xalan.xslt.extensions.XLink"
extension-element-prefixes="xlinkext">
<xsl:output method="html"/>
<xsl:template match="/">
<html>
<body>
<xsl:apply-templates/>
</body>
</html>
</xsl:template>
<xsl:template match="name">
<xlinkext:linkable select="." type="simple" />
</xsl:template>
</xsl:stylesheet>
If any XLink information is specified for the node that is selected in the
xlinkext:linkable node, it would output it as a link based on the currently
specified output method and/or specified doctype-system and doctype-public
attributes of the xsl:output node (identifying a specific type of XML like
WML). You would want the creator of the XSL to be able to specify *how* the
link is generated, and they could possibly want it to output in any of the
following ways:
* If there are multiple destinations, output some Javascript that will
create a popup window when the link is clicked on to allow selection between
the multiple destinations.
* If there is a single destination, create a simple <a href="..."> link.
* Allow the user to specify a java class to intercept the links and output
it how the user wants it output.
* If there isn't any link information, just output the value of the node.
* Output it based on a template the user specifies. For example:
<xlinkext:linkable select="." type="template">
<xlinkext:for-each>
<b><a><xsl:attribute
name="href"><xlinkext:current-link-href/></xsl:attribute></a></b>
</xlinkext:for-each>
</xlinkext:linkable>
Obviously the way the user would output the links would vary based upon the
targetted device.
Of course, it is also possible that the linkbase stuff could occur in the
XSL as well by adding a linkbase attribute to the xlinkext:linkable element.
One of the weak points of this solution is that linking isn't transparent.
You still have to mark things as linkable in order to be able to add them to
the linkbase. You could, of course, mark everything linkable to begin with,
and then you'd have free reign, but it obviously adds a lot of complexity to
the XSL.
So what's the easy answer here? I'm not sure...I think a
LinkbaseTransformer would be a great first step, but that'll only give us
support for applications that already support XLink. If we want to go the
next step and accomodate devices that don't yet support XLink, I think some
serious brain power needs thrown at that problem. I definitely want to see
this happen, though, because it adds that crucial (IMHO) site flow control
to Cocoon.
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.
- Sean T.
Re: [RT] XLink [*LONG*] (was Re: XLink)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 13:36 -0700 17/12/00, Timm, Sean wrote:
>Jeremy Quinn [mailto:jeremy@media.demon.co.uk] 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.
>
><snip/>
>> 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
[snip]
>Cocoon is great for separating content, logic, and presentation, but it is
[snip]
>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
>linkbases.
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.
Ditto
>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">
<about/><author/><content/><history/><keywords/>
<link xlink:to="theory.3"/>
<section id="theory.5">
<about/><author/><content/><history/><keywords/>
<link xlink:to="theory.5.2"/>
<link xlink:to="theory.5.7"/>
</section>
<link xlink:to="theory.2"/>
<link xlink:to="theory.4"/>
</section>
</document>
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
xlink:type="arc"/>
The linkbase looks like this (please excuse the wrapping):
<linkbase id="theory"
xmlns:xlink="http://www.w3.org/1999/xlink" >
<map xml:base="http://192.168.0.2/xml/theory/">
<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"
xlink:href="http://www.nettime.org/nettime.w3archive/199909/msg00046.html"/>
<loc xlink:label="ma.theory.1.6" xlink:title="The Hi-Tech Gift Economy"
xlink:href="http://firstmonday.dk/issues/issue3_12/barbrook/index.html"/>
<loc xlink:label="ma.theory.1.2" xlink:title="The Digital Economy"
xlink:href="digitalEconomy/index.xml"/>
.......
</linkbase>
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
<document>.
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"/>
</link>
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 ;) <http://bewoner.dma.be/bruno2/xlinkstuff.tgz>
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
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>