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/12/31 12:43:01 UTC
Re: cvs commit: xml-cocoon/webapp/stylesheets
dynamic-page2html.xsl
At 22:30 +0000 30/12/00, giacomo@locus.apache.org wrote:
> +++ samples.xml 2000/12/30 22:30:27 1.1.2.11
> @@ -52,7 +52,7 @@
> Simple XSP example.
> </sample>
> <sample name="Simple SQL" href="sql/sql-page" xlink:role="dynamic">
Hi Giacomo,
It's great to see you getting Actions going!
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.
This may cause us problems using compliant XLink Processors in the future?
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 ... xlink:role="http://apache.org/cocoon/XLink/role/dynamic"/>
<sample ... xlink:role="http://apache.org/cocoon/XLink/role/static"/>
Does this make sense?
Forgive me if I am barking up the wrong tree ;)
Happy New Year!
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: cvs commit: xml-cocoon/webapp/stylesheetsdynamic-page2html.xsl
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
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 ...
>>xlink:role="http://apache.org/cocoon/XLink/role/dynamic"/>
>> <sample ...
>>xlink:role="http://apache.org/cocoon/XLink/role/static"/>
>>
>> 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
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: cvs commit: xml-cocoon/webapp/stylesheetsdynamic-page2html.xsl
Posted by Giacomo Pati <gi...@apache.org>.
Happy new year, Jeremy
Jeremy Quinn wrote:
>
> At 22:30 +0000 30/12/00, giacomo@locus.apache.org wrote:
>
> > +++ samples.xml 2000/12/30 22:30:27 1.1.2.11
> > @@ -52,7 +52,7 @@
> > Simple XSP example.
> > </sample>
> > <sample name="Simple SQL" href="sql/sql-page" xlink:role="dynamic">
>
> Hi Giacomo,
>
> It's great to see you getting Actions going!
>
> 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).
> 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 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 ... xlink:role="http://apache.org/cocoon/XLink/role/dynamic"/>
> <sample ... xlink:role="http://apache.org/cocoon/XLink/role/static"/>
>
> Does this make sense?
Can you tell me what the general benefit of using it at all is?
> 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 :)
Giacomo