Return-Path: <STimm@mailgo.com>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 52235 invoked from network); 17 Dec 2000 20:36:23 -0000
Received: from firewall.altacast.com (HELO exchange.altacast.com)
 (63.84.216.2)
  by locus.apache.org with SMTP; 17 Dec 2000 20:36:23 -0000
Received: by firewall.altacast.com with Internet Mail Service (5.5.2653.19)
	id <Y0PVGX9S>; Sun, 17 Dec 2000 13:36:17 -0700
Message-ID: <85CDFD92C550D311A1A40008C7DFA81A37B39E@firewall.altacast.com>
From: "Timm, Sean" <STimm@mailgo.com>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: [RT] XLink [*LONG*] (was Re: XLink)
Date: Sun, 17 Dec 2000 13:36:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

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.