Return-Path: Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org Received: (qmail 11340 invoked by uid 500); 8 Sep 2002 17:53:48 -0000 Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: forrest-dev@xml.apache.org Delivered-To: mailing list forrest-dev@xml.apache.org Received: (qmail 11331 invoked from network); 8 Sep 2002 17:53:47 -0000 Received: from www2.kc.aoindustries.com (209.15.201.84) by daedalus.apache.org with SMTP; 8 Sep 2002 17:53:47 -0000 Received: from outerthought.org (stat88-18.adsl.xs4all.be [195.144.88.18]) by www2.kc.aoindustries.com (8.11.6/8.11.0) with ESMTP id g88Hrop01452 for ; Sun, 8 Sep 2002 12:53:50 -0500 Message-ID: <3D7B8EAD.7040601@outerthought.org> Date: Sun, 08 Sep 2002 19:53:49 +0200 From: Marc Portier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: forrest-dev@xml.apache.org Subject: Re: Link-Addressing, and breaking up the sitemap References: <3D738313.3060009@outerthought.org> <3D738615.40003@apache.org> <3D7387E4.8020603@outerthought.org> <3D74A221.7020802@outerthought.org> <20020905041939.GA7459@expresso.localdomain> <3D770D1B.1010707@outerthought.org> <20020905124031.GE8900@expresso.localdomain> <3D777A1A.7090604@outerthought.org> <20020906052608.GA2014@expresso.localdomain> <3D78B5B6.7050707@outerthought.org> <20020906162946.GB8812@expresso.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Status: O X-Status: X-Keywords: Jeff Turner wrote: > On Fri, Sep 06, 2002 at 04:03:34PM +0200, Marc Portier wrote: > ... > >>>Okay. What happens to the HTML that contained the link? We need to >>>rewrite the link to point to the 'location' attribute. As the link is >>>part of the contents, which is rendered by the sitemap, we need an XSLT >>>or something that rewrites links: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ... >>> >>> >>>Suitably generalized, of course. >> >>mmm, the idea would be that you write your documents in such a >>way that they use a common ref-prefix '/bar' for say docs >>generated by foo... >> >>then you mention >> >> >>and tzadaam they get merged in > > > That's the goal.. > > >>it is of course a bit naieve? >>in my first attempt at describing this I also thought about >>reference-aliases for the case where you can say >> >> >> >> >> >>this would mean that there are still documents that would use the >>old or alternative reference-prefix /old-bar resp /bar2 when they >>should be using /bar > > > Don't see the need for extra prefixes. URIs are meant to uniquely > identify the resource. > yep, main reason why I dropped it later on... > >>for those I think some tuned transformer could be created >>suggestions: >>- SAX filtering on anything that looks like a link-attribute? > > > Make LinkSerializer configurable? > surely a little babe I'ld like to have a look into... pointers/tips? also some elaboration on how you'ld see the configuration look like and modify behaviour? (even if the new line of thinking would be not to have multiple prefixes alias to the same kind of thing, your new line of thinking still requires us to start thinking on this, no?) > >>- having as config a small file that is generated from the >>original one, (or is just the original one where it is >>xpath-working out what it needs) >> >> >>still, a 2nd line kind of feature if you ask me >> >> >>>Minor issue: if we're rewriting links, why bother copying the javadocs >>>inside the Cocoon context? We could just prepend '../javadocs', tell >>>Cocoon to ignore those links, and keep Javadocs outside. No need for Ant. >>> >> >>I feared that the javadoc example would lead to this.... >>I was supposing that maybe one would want to e.g. start from >>xml-javadocs ore something like that? > > > Then /xjdoc links get pointed to a different place than /jdoc. > > Btw, how do you feel about a pseudo-protocol notation, > 'javadoc:someClass'. Since we're going to need link rewriting anyway, > might as well not confuse users by suggesting that a real '/jdoc' > directory should exist. > indeed... I like it a lot. only constraining thing would be a bit the fact that considering 'part of content' as 'protocol' might be confusing as well? maybe URN notations with their namespace-parts are then the ideal go-between? Never done it actually but would we then get something like urn:javadoc:className ? just thinking out loud here... > >>and there is other content to consider, no? > > > Link rewriting is useful all over the place. I've got links like: href="elem:httpRequest">, which means "link to the section documenting > the httpRequest element". A stylesheet then replaces that with href="httpRequest.html">. Alternatively, if producing a PDF, it gets > converted to a . > > Given a suitably smart link rewriter, and some support in the crawler, > and I think we can have links that are genuinely independent of the > output format and filesystem. > japjap, here you... > >>>So if I'm not mistaken, the whole thing boils down to one link-rewriting >>>stylesheet. >>> >>>I'll try implementing it on my own project now. >>> >> >>let us know where it's leading you... > > > Javadoc links are working, eg: > Pretty trivial to implement. With one stylesheet modification I can link > to either the online javadocs or locally produced javadocs. > yes > I don't know how "deep" links would work though. Right now I've got an > xdoc like this: > > > >
Anteater tags > ... >
httpRequest > ... >
>
> > > > And I'm trying to figure out how to link to the 'httpRequest' section > from another page. Probably an id attribute, which gets rendered in HTML > as would work. > sounds like DTD-votes and xslt work... on the other hand: this talk about link-rewrites makes me dream about fragment-identifiers with xpath/xpointer expressions... would be great feature if the link-rewriter could also just rewrite the expression into the matching fragment-identifier the style-sheet is now throwing in for the inline-document-local TOC? > --Jeff > this feels like we're getting somewhere. no? -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center mpo@outerthought.org mpo@apache.org