Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 5927 invoked from network); 3 Jan 2001 12:53:12 -0000 Received: from orion.uk.insnet.net (194.177.174.244) by h31.sny.collab.net with SMTP; 3 Jan 2001 12:53:12 -0000 Received: from [10.0.1.123] (ruins.risk2risk.com [213.38.161.125]) by orion.uk.insnet.net (8.9.3/8.9.3) with ESMTP id MAA09071 for ; Wed, 3 Jan 2001 12:52:57 GMT Mime-Version: 1.0 X-Sender: media@pop3.demon.co.uk Message-Id: In-Reply-To: <3A51A92A.B19A88ED@apache.org> References: <20001230223028.40814.qmail@locus.apache.org> <3A51A92A.B19A88ED@apache.org> Date: Wed, 3 Jan 2001 12:40:58 +0000 To: cocoon-dev@xml.apache.org From: Jeremy Quinn Subject: Re: cvs commit: xml-cocoon/webapp/stylesheetsdynamic-page2html.xsl Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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? >> >> >xlink:role="http://apache.org/cocoon/XLink/role/dynamic"/> >> >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