On Sat, Jun 28, 2003 at 11:07:45AM +0100, Upayavira wrote: > On 28 Jun 2003 at 18:45, Jeff Turner wrote: ... > > > <map:match pattern="page.html"> > > > <map:generate src="page.xml"/> > > > <map:transform src="before-links.xsl"/> > > > <map:transform type="gather-links" src="identify-links.xsl"/> > > > <map:transform src="after-links.xsl"/> <map:serialize/> > > > </map:match> > > > > > > So there's no hidden link gatherer. And you've got a single xslt to > > > filter, etc. Not specifying src="xxx" skips the xsl stage. The > > > output of this xsl would be xml conforming to a predefined > > > namespace. > > > > Having eliminated the dont-follow-these-links use-case, I don't see a > > use-case for XSLT transformations, so it simplifies to > > > > <map:transform type="gather-links"/> > > So are you saying you can manage without the XSLT stage?
I'm not sure, perhaps you can advise. In Forrest we filter the links to: - Remove API doc links - Remove links to directories, which break the CLI - Remove image links that have been hacked to work with FOP 1) belongs in cli.xconf. Perhaps the new CLI handles 2) better than the original. I think 3) is obsolete, as LinkSerializer ignores XSL:FO-namespaced links anyway. > Perhaps I should explain what I had in mind a bit more with that - I > guess I would call it a tee, a pipeline element with one input and two > outputs. The input is passed unchanged on through to the next stage in > the pipeline. But it is also passed through an XSLT before links are > gathered from it. I'd call it a hack ;) Why favour XSLT and not STX, or any other transformer? What about XSLT parameters? etc. If people need XSLT, let them use a link view. I'd suggest just sticking with the basics: <map:transform type="gather-links"/> Which isn't a hack. In fact it would be great for Forrest, because we only have a few matchers where links are relevant. All the cocoon: and image pipelines could go without. Also, it resolves another little dilemma I've had with link views. It's all very well having the notion of a cross-cutting 'view', but there's no way to override the 'view' for a specific pipeline. With an explicit gather-links transformer, one could have different link analysis for each pipeline. A *.css pipeline could list @import's as links, for example. > > It certainly fixes the hard-wired'ness problem you mention above (that > > 'content' != XML before the serializer). > > And it sounds as if it could be a trivial solution. 'Solves' the cocoon: sub-pipeline problem too. --Jeff > > Upayavira
