On Sat, Jun 28, 2003 at 03:38:55PM +0100, Upayavira wrote: ... > Okay. How about defining a namespace <links:link href="xxxx"/> which > gets consumed by the transformer, that way you choose in your > previous XSLT which links you want to be spidered by presenting the > links in that <links> namespace (and then repeat them for the sake > of the output).
Sounds good. So you mean, eg, transforming <a href="..."> into <a href="..." link:href="...">, and the gather-links transformer uses the link:href attribute? ... > Now the only question that remains is whether to have an implicit > gatherer if no explicit one is specified. I'd probably say no, as > other discussions have erred away from hidden things like that. +1 > I think that telling the sitemap where your links are is a pretty > reasonable adjustment to your site. In fact, we could have two > transformers - one that just looks for hrefs and xlinks, and another > that uses a links namespace - the former would make it real easy to > convert your site for spidering, and the latter providing a method > to do complex link management. +1, was just going to suggest that. > Another question - do we still leave link view (two pass) link > following in the CLI? Or does this method deprecate and thus replace > it? I still have the feeling that a link-gatherer transformer is mixing concerns a bit, and that two-pass is conceptually nicer: - We're abusing the name 'transformer', since nothing is transformed. If we're really going to go this way, let's define a new sitemap element, <map:link-gatherer/>. - Link gathering is irrelevant for online situations, so we pay some performance penalty having a link-gatherer transformer. This illustrates why I think it mixes concerns. - It's easy to forget to define a link-gatherer transformer for new pipelines. Link-view is cross-cutting and doesn't have this problem. I'm not very familiar with the code; is there some cost in keeping the two-pass CLI alive, in the faint hope that caching comes to its rescue one day? > Thanks for engaging with me on this - I appreciate it. Thank _you_; an improved CLI will make Forrest significantly more usable. --Jeff > Regards, Upayavira >