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 Tue, 19 Dec 2000 12:23:41 GMT
At 20:50 -0700 18/12/00, Timm, Sean wrote:
>Jeremy Quinn [] wrote:
>I'm finishing up a project this week, so I don't have a lot of time to go
>over this right now, but I wanted to briefly respond...

I'm up to my neck in it too ..... this XLink stuff is for a subsidiary project.

><big snip/>
>>Sean, have you seen the XLinkProcessor written by Bruno Dumon and Bert
>>It covers all this ground, I cannot make it work properly so I am just
>taking the ideas ;) <>
>I've got it downloaded, but I haven't taken a look at it yet.  If I remember
>correctly, it generated simple XLinks from something...or maybe it
>interpreted simple XLinks into something...anyway, it was targetted at an
>early spec., so I'm not sure how relevant it is right now.  We can
>definitely take a look at it, though.

Earlier spec, 'fraid so.

>>I am still trying to understand some of the subtleties of the XLink Spec,
>what are "resources" and "roles" good for? ........
>Well, "resources" are what you traverse between, right?  Are you referring
>to local resources (ie. the resource-type)?

Yes, xlink:type="resource", it has to be a URL according to my reading of
the spec. Quite what it is for I do not know. Incedentally, Stefano's
crawler uses the "xlink:role" for application specific data, ie. should
this resource be crawled?

>XLink has a lot of behavior
>that is left up to the implementing application, so I've got the impression
>that local resources might often be populated automagically by the
>application.  I'm not too sure about roles, either, but I get the general
>impression that they are, again, application-specific in that they provide a
>means of semantically identifying various links and the roles they play, and
>it would be up to the application to determine how to handle them.

I'd like to find out what the planned use was, before deciding to use it
for our own purposes .....

>This is
>why I believe that Cocoon needs to be able to not only do the LinkBase
>functionality, but we should also provide the means to do the link
>interpretation...because much of the XLink spec. is left up to the
>application to do with as it sees fit.

Maybe I misunderstand what you mean.
Could you clarify what you mean by "link interpretation"?
My feelings at the moment is that as much of that as possible should be up
to the StyleSheet to decide how links should be rendered according to the
needs or capabilities of the output format.

One of these days browsers will be able to use XLinks directly .... someone
may want to use de-referenced LinkBases for content agregation etc.....

>>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
>>        <2> Arbritary - all other links
>Could you elaborate more on this?

<1> Structural
The site I am developing (that is driving my use of XLink) has a natural
hierarchy. A structure of child/sibling/parent relationships between

I am using XLink/LinkBase and internal structure to map this natural
hierarchy, allowing documents to automatically "discover" their immediate

<2> Arbitrary
Lots of the pages have arbitrary links to other pages either within the
site or to external sites. The links do not constitute any part of the
hierarchy of the documents, but are cross references to relevant material.

Most of the information about this structure comes from the internal
hierarchy of the XML in each document, each section in that hierarchy is
tagged with an ID, that references the LinkBase to derive a URL.

Arbitary links are either part of the content of each section as written by
the author (again de-referenced via the LinkBase), or placed into the
linkbase as xlink:type="arc".

During XLink processing, inline links get rendered inline, arc type links
that exist only in the LinkBase, are provided to the document in a <links/>

>>It would be great to work together on a spec for this.
>I'd be very interested in doing 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?
>Fine by me...I'm mainly interested in C2, so I'd be most interested in
>working on the Transformer.

Fair enough .... I understand DOM reasonably well.
I still need a little project to do in SAX, as I still have not got to
grips with it yet, but hey, there will be plenty of opportunities elsewhere

regards Jeremy

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <>     		 <>
    <phone:+44.[0].20.7737.6831>        <>

View raw message