cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: cvs commit: xml-cocoon/webapp/stylesheetsdynamic-page2html.xsl
Date Wed, 03 Jan 2001 12:40:58 GMT
At 11:10 +0100 02/01/01, Giacomo Pati wrote:
>Happy new year, Jeremy

And the same to you, old chap !

>Jeremy Quinn wrote:
>> I am slightly worried about the use of "xlink:role" here.
>> According to the latest XLink specs, the value of this attribute has to be
>> a URL.
>The fact is that I have no clue how this attribute has found it's way
>into the sitemap (and I and Berin as well have simply copied it from an
>already existing entry :( ). The CVS history tells my ... (oh shit locus
>is down again). It could be that it was to prevent the commandline
>environment to crawl these links but it doesn't do so yet. There has
>been a discussion about that several week ago if and how we should make
>it possible to tell the commanline environment not to crawl into some
>URI (but it was at the sitemap level to prevent it).

Yes, my understanding is that this was done by Stefano when he was working
on the command-line renderer. I think when he did this, his particular
usage was legal, the spec changed afterwards.

Looking at the XLinkHander, XLinkConsumer, LinkSerializer, Constants etc.
in C2,I believe the command-line renderer uses LinkSerializer to only
render XLinks that have an xlink:role equal to "static".

>> This may cause us problems using compliant XLink Processors in the future?
>This could be a problem, sure (I'm not that deep into XLink to tell you
>for sure)

I did a bunch of work with XLink over the holidays (successfully :)

I currently use XInclude to include a LinkBase into my XML files, and an
XSL to de-reference Arcs etc. from the LinkBase.

Sean Timm and I were discussing writing an XLink or LinkBase Transformer
that would do this automatically (instead of using XInclude and XSL),
caching the linkbase etc.

This is where we might get into trouble. If the processor was to be written
to tightly match the XLink spec, files that used XLinks for the
command-line renderer would fail to validate if they were also used with
the LinkBase Transformer, as the spec says the xlink:role needs to be a URL.

>> I am still a bit unsure as to the real purpose of xlink:role, but what
>> about using it as a kind of NameSpace instead of a simple value (sorry I've
>> not explained that very well)
>> What if we defined URLs to represent the different states, a bit like
>> setting features in a SAX Parser?
>>         <sample ...
>>         <sample ...
>> Does this make sense?
>Can you tell me what the general benefit of using it at all is?

I am speculating ....
If we want to use xlink:role for this application-specific purpose, that is
fine by me, but it would be easier for everybody if we used it in a
compliant way.

When I saw that Parsers use URLs for configuration strings, I thought maybe
this could be the solution to using xlink:role as well.

Maybe there is a better solution :)

>> Forgive me if I am barking up the wrong tree ;)
>	This is what I like about the Cocoon-dev mailing lists. You often
>	learn new words to express yourself :)

Yea, but I am not learning any Italian or German colloquialisms :)

regards Jeremy

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

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

View raw message