forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: Link-Addressing, and breaking up the sitemap
Date Sun, 08 Sep 2002 17:53:49 GMT


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:
>>>
>>><xsl:template match="link">
>>>  <link>
>>>    <xsl:attribute name="href">
>>>      <xsl:if test="@href = 'doc'">
>>>        <xsl:value-of select="./src/documentation/content/xdocs"/>
>>>      </xsl:if>
>>>      <xsl:if test="@href = 'mail'">
>>>        <xsl:value-of select="..."/>
>>>      </xsl:if>
>>>      ...
>>></xsl:template>
>>>
>>>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
>><part name="bar" location="./build/where-foo-dropped-it" />
>>
>>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
>><part name="bar" location="./build/where-foo-dropped-it" >
>>   <ref-alias name="old-bar" />
>>   <ref-alias name="bar2" />
>></part>
>>
>>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: <link
> href="elem:httpRequest">, which means "link to the section documenting
> the httpRequest element". A stylesheet then replaces that with <link
> href="httpRequest.html">. Alternatively, if producing a PDF, it gets
> converted to a <fo:basic-link>.
> 
> 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: <link href="javadoc:org.apache.foo.Bar">
> 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:
> 
> <document>
>   <body>
>     <section><title>Anteater tags</title>
>     ...
>       <section><title>httpRequest</title>
>       ...
>       </section>
>     </section>
>   </body>
> </document>
> 
> 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 <a nam=".."> 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


Mime
View raw message