You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@media.demon.co.uk> on 2000/10/03 11:22:44 UTC
XLinks & LinkBase
Hi All,
A while ago some Belgian guys released an XLink Processor for C1.
http://bewoner.dma.be/bruno2/xlinkstuff.tgz
I have not actually made it work yet, it's based on Java 2 :(
I have been looking at this recently, it could help solve a tricky set of
problems I have with a new site I have in mind.
The system basically allows you to have a "LinkBase" file which stores
XLinks and XLink "arcs" which define all the links in your site, which is
processed at runtime (caching in your session) placing all relevant links
into your document, to be sorted out by XSL.
What I'd like to know, is what future does this type of system have in
Cocoon 2?
By the look of Stefano's fantastic work on C2's CLI, XLinks are going to be
heavily used in C2, will the concept of a LinkBase fit into this picture?
Thanks for any help
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>
Re: XLinks & LinkBase
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 16:13 +0200 03/10/00, Stefano Mazzocchi wrote:
>Jeremy Quinn wrote:
>> The system basically allows you to have a "LinkBase" file which stores
>> XLinks and XLink "arcs" which define all the links in your site, which is
>> processed at runtime (caching in your session) placing all relevant links
>> into your document, to be sorted out by XSL.
>>
>> What I'd like to know, is what future does this type of system have in
>> Cocoon 2?
>
>This is a very interesting question. XLink is clearly a heavy
>specification and the way I used it for the CLI was nothing more than
>catching all the locations so that the crawler knows where to go next.
Dear Stefano,
Thanks for your excellent reply.
I need a while to do justice to it.
I don't know if I completely agree with what you wrote, but you made me
realise I had holes in my own ideas. I need some time to think about this,
and I'll get back to you.
Some of the things in your recent RT point to the issue I am trying to
solve .... namely a deep heirarchy of parent/sibling/child relationships
where each needs to "know" about the other, without duplication of data and
without requiring multiple lookups into each relation to get that
information.
Anyway, I need some time away from what is filling my head at work to
formulate this properly :)
Thanks
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>
Re: XLinks & LinkBase
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
>
> Hi All,
>
> A while ago some Belgian guys released an XLink Processor for C1.
>
> http://bewoner.dma.be/bruno2/xlinkstuff.tgz
>
> I have not actually made it work yet, it's based on Java 2 :(
>
> I have been looking at this recently, it could help solve a tricky set of
> problems I have with a new site I have in mind.
>
> The system basically allows you to have a "LinkBase" file which stores
> XLinks and XLink "arcs" which define all the links in your site, which is
> processed at runtime (caching in your session) placing all relevant links
> into your document, to be sorted out by XSL.
>
> What I'd like to know, is what future does this type of system have in
> Cocoon 2?
This is a very interesting question. XLink is clearly a heavy
specification and the way I used it for the CLI was nothing more than
catching all the locations so that the crawler knows where to go next.
The crawler doesn't need to know anything more... things like title,
action, role and such are made for the client side and for this reason
they are ignored.
What you are talking about here is something different, if I understand,
we might want to call it "link delegation": instead of having an
hardwired chain of links, you delegate the link creation at an external
source that reacts on enviornmente parameters.
This is a very interesting concept indeed.
But I'm afraid this might well be flexibility syndrome... let me explain
why:
In a famous paper by Tim Berners-Lee, URIs are separated in two groups:
names and addresses. Some believe that URN are names and URL are
addresses, but this is not correct.
For example, is
http://xml.apache.org/cocoon/index.html
a name or an address? it's an address, but what about
http://xml.apache.org/cocoon/index
it's much more name, but still address.
TBL himself tells there is no clear distinction between addresses and
names, but a good decription of a good URI is 'the one that doesn't
change over time'.
So would you use "http://xml.apache.org/cocoon/index.html" as a
namespace URI? of course not, why?
- it may change format (so the extension is *always* wrong in
namespaces)
- it may change virtual host
also
- it may change project name
- it may change domain
- it may change protocol
but these are much less likely to happen...
interesting enough, the most stable part of the URI is "index" since
once decided it can remain there almost forever given the low amount of
interaction with the rest of the URI.
So, the best URI for the above resource is
http://apache.org/cocoon/index
but this can be used only for unrevisioned resources.
The W3C adopts a URI schema for their namespaces that uses dates.... I
personally believe this to be a mistake, but indeed a minor one compared
to other URI spaces I've seen.
For versioned resource, the URI should be something like
http://apache.org/[project]/[resource]/[version]
for example
http://apache.org/cocoon/xsp/2.1
or
http://apache.org/cocoon/xsp/taglib/cookie/1.2
which, can be used "both" as names and addresses (even if TBL is against
such a thing) I think this is useful because it allows, in case of
schemas, to obtain the schema from the URI directly... also, using the
version "latest" one should be able to obtain the latest version of the
resource
http://apache.org/cocoon/xsp/taglib/cookie/latest
Ok, now let's go back to "link delegation", this is more or less what
the W3C does with their URIs: what is the URI of XLink 1.0? If I don't
know the year of its creation, I have no clue... I have to look it up.
The above LinkBase enhances this: what is the address of the name
"/next-screen" if I'm resource "/login" and the user has logged in?
I honestly believe the above is very HARMFUL, this is why I don't like
Turbine and equivalent systems: their URI space is too delegated, it's
indeed flexible, but it's impossible for users to connect to a specific
resource without going to the portal and then go the appropriate
resource.
A web of turbines is a nightmare for search engines... it's the dead of
the (yet to be created) semantic web.
C2 uses a sitemap instead: link delegation is *never* done. Why? to
enforce SoC!
You need solid contracts to parallelize development... link delegation
breaks this... even W3C will face the need for such a link translation
in the future when people won't recall if the first XLink spec was 1999
or 2000... or why the 1999/xlink has actually a release date of 2000.
URI must be meaningful, consistent and guessable.
W3C should be the one that shows the way... but their URI space is yes,
meaningful, but inconsistent (look at the RDF namespace, please!) and
not guessable (how the hell do I know what year was used to create
version X.Y of the ZZZ spec?)
Link indirection appears cool at first because allows you to recompose
your web resources at will without having to touch anything, but this is
BAD! You should go thru the pains of hell to modify even a simple link
to your logo! so, forget about
<img src="images/cocoon.gif"/>
but welcome
<img src="images/logo"/>
which is future-compatible and portable for other projects!
Since it's hard to distinguish between names and addresses, the sitemap
forces you to think at names that are *both* good names and valid
addresses and gives you the flexibility to perform all this without
requiring anything else.
(yes, C2 with actions does replace Turbine functionality completely...
we just need a WebMacroGenerator (if you really care) and few Avalon
blocks underneath and we're done).
> By the look of Stefano's fantastic work on C2's CLI, XLinks are going to be
> heavily used in C2, will the concept of a LinkBase fit into this picture?
In theory, there is no technological limitation for link indirection....
you could easily write your LinkLookupTranslator that connectst to a
LinkBase to perform link translation... but would *highly* discouradge
anybody from using it.
Think about this: good programming practices cristallize into design
patterns.... are there any design patterns for URI spaces? No...
everybody reinvents the wheel every day.
Here is even worse, you are giving them the ability to reinvent the
wheel without even having to touch the files: something like this is
like asking for broken links all over the place.
Consider Ant build files: they are free form, you can do almost anything
you want...but almost all projects that use Ant use more or less the
same design patterns for their build systems and the same target
names....
I forecast the exact same thing for sitemaps.
Also, I'll make sure I write a big paper describing a bunch of design
patterns for URI spaces quoting all the relevant information from TBL
and Nielsen (of useit.com fame)
But I might be missing the picture entirely... who knows.. anyway, one
thing is for sure: having hard URIs does less harm than having soft
ones.
--
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 ---------------------