forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Link-Addressing (Re: Semantic linking (Re: [VOTE] Usage of file.hint.ext convention))
Date Tue, 03 Sep 2002 11:50:57 GMT
Babes,

What Steven calls 'intense mind battle' is in fact pure 
'tootbrush torture'... so here is my +1 on the reached consensus
(just to make him stop, aaaargh)

While we are having some momentum in discussing the URI design it 
is maybe not a bad idea to talk about the leading part of the URI 
(we just covered the trailing part)

Looking at the URI concerns I think we covered: 1. deciding on 
rendition - 2. hinting (or autodetecting via CAP) the pipeline to 
produce the IMF for the two step view
what remains though is pure 3. addressing (finding).

the easiest one is linking to external documents: we add a 
http://-leading URI to the picture and the crawler leaves it just 
as is in the produced HTML.  In fact even 'external' (== docs 
forrest does not know about, not passing through the sitemap) 
that 'accidentally' are serviced on the same server could be 
handled like this. ("http://[project-server]/javadoc" just means 
that forrest isn't providing help for tighter linking to javadoc 
stuff yet)

next would be links between hand-written xdocs: I would propose 
to make all of these relative, as to inline or referenced 
resources they bring along.  To me this makes sense, but maybe 
I'm overlooking something...

finally there is the stuff we've been kind of ignoring:
junit-reports, mailarchives, javadocs, integration-build-reports 
(alla gump), 'ze metrix', maybe syndicated news (allthough 
pulling those through a live generator makes  more sense),....

I would be -1 on just saying that all of this will at all times 
be covered (ignored) via http://-leading url's we don't care 
about.  My -1 however entitles me to a proposed solution :-)

- the different content parts will have complete separate 
relative naming & addressing strategies (copying them all into 
/content/xdocs will ensure name collissions)
- so to avoid name collissions this probably ends up being 
different subdirs of ./content/ next to the xdocs... these should 
be copied over into the cocoon context dir before webapp-wrapping 
  or cli-crawler starts off

somewhere forrest needs to be told, for each of these parts
- where the raw-content is on disk
- by use of which root-ref these documents will be referenced to

this could be fixed or predefined by us forresters so we can make 
the sitemap look for

href --> drive location <-- {copied in by forrest-ant based on:}
/jdoc/**      --> /content/jdoc <-- ${forrest.content.jdoc.dir}
/news/**      --> /content/news <-- ${forrest.content.news.dir}
/junit/**     --> /content/junit<-- ${forrest.content.junit.dir}
/mail/**      --> /content/mail <-- ${forrest.content.mail.dir}
/doc/** (or not matched previously:)
/**           --> /content/xdocs<-- ${forrest.content-dir}


only I'm not that particularly fond of "fixed and predefined"
if we could agree to move up our current URLs to be in /docs
then the matcher remains a simple /** for all (no need for any 
sitemap-generation I expressed earlier)
(and the CAPs already solve the fact that there could be multiple 
xml-doctypes everywhere)

still, allowing forrest-endusers to assemble their content in 
this way would mean
1. they have their forrest-working ant-task depend on all the 
other content-generating tasks (easy)
2. they have a mechanism to tell forrest where all that stuff is 
around... (favour this above letting them build the cocoon 
context dir themselves?)

for this last part I still think a simple forrest-config file 
makes the most sense: (since I don't know how to have ant run 
through properties that you don't know about at design time)

<content>
   <part name="doc"
         location="./src/documentation/content/xdocs"/>
   <part name="mail"
         location="..." />
   <part name="jdoc"
         location="..." />
</content>

with the knowledge of the current bot we could easily build out 
of this a dynamic/embedded ant piece that gets to copy over this 
stuff to the cocoon context dir in separate dirs that == the 
part-name

what remains though is the knowledge of the "default-page" for 
each of the parts... what if we link to just /doc/ ? must there 
then be some /content/doc/index.* ?
if we make this flexible and possibly differrent for the various

there is one other thing we could mingle in here, and that is the 
tab-definitions:
<content>
   <tab label="must reads" default-part="doc">
     <part name="doc" location=".." />
     <part name="jdoc" location=".." />
   </tab>
   <tab label="community" defaut-part="mail">
     <part name="mail">
   </tab>
   <part name=".." location=".." />
</content>

so we could also generate a tabs.xml :-)

any other ideas?

-marc=
PS: this kind of joins with the "Working on Forrest" thread 
currently over at krysalis-centipede, no?
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message