Hello Jeff, thanks for replying. Let's see whether I can shed some more light on my predicament. :-)
On Saturday 30 August 2003 11:55, Jeff Turner wrote: | Cool :) If you come up with something generic and useful, we'd be | very interested in including it in Forrest[1]. Kal Ahmed once brought up | the idea of using TMs in Forrest when the project was just starting: | | http://marc.theaimsgroup.com/?t=101647336300007&r=1&w=2 | | Forrest is just now getting to the stage of needing an internal | metadata model (TMs or RDF). <plug type="shameless">Before we get into an off-topic discussion here, let me suggest that you join the tm4j-users mailing list and see if TM4J is right for you?</plug> | > <!-- ... --> | > <map:transformer name="links" | > src="org.apache.cocoon.sitemap.LinkGatherer"/> | > <!-- ... --> | > <map:pipeline id="links"> | > <map:match pattern="links"> | > <map:generate type="file" src="src/fgh.xtm"/> | > <map:transform type="xslt" src="xsl/tm.xsl"> | > <!-- lots of parameters here --> | > </map:transform> | > <map:transform type="links"/> | | I don't think you're meant to be explicitly adding the LinkGatherer. | It will be added automatically to the pipeline, just before the | serializer. And then, only when you are using the 'new' CLI | implementation (passing --xconf=cli.xconf to org.apache.cocoon.Main). I realize that. I only set up that pipeline to determine whether any LinkGatherer-related issues would also pop up in the servlet environment, or whether they were limited to the CLI. | FYI, LinkSerializer is usually used in conjunction with a 'links' | view. Yep. That's how I originally found out about the LinkSerializer-related issue I was describing (LinkSerializer finding some links, but not all). | Btw, Forrest's Ant script has examples of both the new (linkgatherer) | and old (link view) CLI usages in its script: | | http://cvs.apache.org/viewcvs.cgi/xml-forrest/src/resources/forrest-shbat/f |orrest.build.xml?rev=1.82&content-type=text/vnd.viewcvs-markup I checked forrest.build.xml, and replaced my cli.xconf with the one used by forrest (adapting filesystem paths, of course). No change. | > Now it's getting a bit bizarre: The LinkSerializer correctly outputs the | > very first link in the result document (a link to a CSS stylesheet), but | > ignores all others (numerous <a href="..."> elements, for example). | | Hmm, not sure. Is your XML using namespaces? But in any case, the | LinkSerializer wouldn't do much good all on its lonesome in a | pipeline; needs to be in a view. My source XML does use the XTM 1.0 NS as its default namespace. The output is XHTML 1.0 Strict and hence uses the XHTML default namespace. As pointed out above, the problem does also occur when using the LinkSerializer in a view. Here's my link view definition: <map:view from-position="last" name="links"> <map:serialize type="links"/> </map:view> The links serializer definition is inherited from the root sitemap. The full output of accessing http://localhost:8080/~fgh/en/index.html?cocoon-view=links is as follows: ../css/tm4web.css Whereas... wget -O - http://localhost:8080/~fgh/en/index.html | grep -o -E "src=\"[a-z:/.0-9]*|href=\"[a-z:/.0-9]*\"" ... yields ... href="../css/tm4web.css" href="person.html" href="topicmaps.html" href="java.html" href="austria.html" href="arno.html" href="tm4j.html" href="fhib.html" href="hico.html" href="http://validator.w3.org/check/referer"; src="http://www.w3.org/ src="http://jigsaw.w3.org/css So if I'm correct, we're dealing with an issue here that's separate from the CLI/LinkGatherer trouble. Aside from the CLI-related issues (which I will go on discussing with Upayavira in a moment, are there any known issues with LinkSerializer? Best regards, Florian --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
