forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: import of xml.apache.org main site into forrest
Date Wed, 05 Jun 2002 19:03:25 GMT
Steven Noels wrote:
> 
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> 
> > Don't want to rain on the party, but are you sure that
> > xml-site/sources
> > contains the *uptodate* sources from all the various projects? I'm
> > pretty sure it doesn't.
> 
> Me, too. This is simply a showcase, and I've only translated the main
> site docs, nothing subproject-specific.
> 
> > This you do it to actually generate the xml.apache.org site
> > or just as a
> > test?
> 
> A test, and a starting ground for the main site.

Ok, very cool.

> > Yes, I wanted to raise this point earlier: there is no need
> > to 'require'
> > a document to have an author. For example, I dislike the fact
> > that even
> > the 'license.html' file has an author on top. It might lead to think
> > that the person is the author of the content of the page, rather than
> > the person who assembled the page from the content authored by other
> > people.
> 
> +1, will make that optional if no-one objects to this.

Great.
 
> > In those situations, it's much better to leave it out of the page.
> >
> > > - Auto-generation of mini TOC's - should this be
> > parametrizable? TOCs
> > > are generated now if sections exist within sections in a
> > document, which
> > > was good for the forrest docs so far, but suboptimal for the content
> > > imported from the main site. On the other hand, these
> > imported docs have
> > > been abusing the DTD to obtain certain visual effects,
> > IMNSHO - so we
> > > could fix the docs, too.
> >
> > I was going to patch this on my local copy removing the 'isfaq'
> > parameter (which semantically sucks!) and adding a 'minitoc'
> > parameter.
> 
> Oops... you're wright ;->

:)
 
> > Now, I believe the best place for 'behavioral skinning'
> > controls should
> > be the book.xml file, which is sort of a high level site map
> > (not in the
> > cocoon's sense of the term, but in the original 'map of the
> > site' sense)
> >
> > So, depending on the document, it's up to who links the
> > documento to the
> > book to indicate whether or not this document should have particular
> > skinning behaviors associated. Examples might be:
> >
> >  1) minitoc yes/no
> >  2) printable version yes/no
> >  3) multipage yes/no
> >  4) ???
> >
> > allowing us to set those behaviors in a single location and separating
> > the concern from the document author simplifis the editor's job of
> > providing the best visual coherence and usability for the entire doco
> > corpus.
> 
> I like this idea, we need to think about this.

I have the impression that you guys might be caught in the good old
"don't who till is ready" ego trap with your 'libre' effort. Release
early and often means also 'release when it barely does anything' so
that people can interact with you *before* you spend months developping
and find out that many things that you considered *very cool* are simply
not needed anymore.

In fact, I don't want the book.xml to be removed by a generator because
no matter how powerful the generator is the book.xml file can contain
much more metadata than any file system... and placing site-related
metadata (such the one I suggested above) inside the document and have
the generator extract it (a-la XPathDirectoryGenerator) seems like the
wrong approach to me since it mixes concerns between the document
authors and those who manage the site (which normally have different
concerns).

I might be totally wrong and I'd love to be because I hate raining on
somebody else's party (I'm abusing this metaphor today) but your "*we*
need to think about this" rang a bell in my head.
 
> > > Please review the result of this little transition exercise and post
> > > other issues you come across with.
> >
> > I'm offline so I don't have access (yet) to what you did, but I have a
> > few comments since I spent yesterday afternoon making myself
> > up-to-date
> > with Forrest.
> >
> > Things to note:
> >
> >  1) the navigation path on top of the page is static. I mean, when you
> > change page, the path doesn't change. We *must* fix this before making
> > Forrest go live.
> 
> -0 - we can do this later on, too. This is another area which could be
> touched by upcoming book.xml alternatives/additions, so we need to be
> careful with this.

Again, it's kind of hard to understand what to plan if we don't even
know what you guys are up to.
 
> >  2) the tabs are fake as well. this is another big showstopper.
> 
> I've seen Bert has a solutions for this, we need to wait and
> investigate.

Yes, our emails crossed, I'll sure take a look at what he did and report
back.
 
> >  3) there is no DTD for .xgump and this makes the changes and
> > toto DTDs
> > obsolete. Having a complete DTD for xgump and removing the obsoleted
> > DTDs is another showstopper.
> 
> Honestly, we don't have much dependencies on Gump. Build & project
> automation is a very political area,  cfr. Nicola's remark. Some careful
> thinking will be required.

I still don't understand why we need to incorporate changes and todos
into a project description file.

Nicola, what's your thinking about this?
 
> >  4) the javadoc DTD is unused and it doesn't seem that nobody is
> > interested in making it work for Forrest ATM. I propose to move it in
> > the scratchpad area.
> >
> > Expect more things as I go along.
> 
> You're absolutely welcome :-)

Cool.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



Mime
View raw message