cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: Link view goodness (Re: residuals of MIME type bug ?)
Date Sat, 28 Jun 2003 11:40:15 GMT
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.


> Upayavira

View raw message