David Crossley wrote:
Today i re-generated the cocoon.apache.org/2.1/ website
which incorporates a few changes to the Daisy sources,
fixes some links that used local hrefs, removes the
old ApacheCon logo.
There were some new documents generated which do not
have any mapping in the navigation. Does someone know
what should happen with them? ...
372.html
378.html
400.html
592.html
692.html
693.html
695.html
696.html
697.html
698.html
699.html
700.html
701.html
702.html
703.html
704.html
705.html
706.html
726.html
728.html
748.html
749.html
-David
I haven't thoroughly checked all of them, but I think they are newly
created and should be part of the "official documentation" rather than
the "legacy documentation".
From my POV (and IIRC there was consensus on this), the
cocoon.apache.org site should contain the documentation for the current
release (2.1.8) which is basically the "legacy documentation".
New documentation for new releases should go into the "official
documentation". However, nobody has decided yet on a structure for that
collection nor for the subsequent structure of the navigation as it goes
onto cocoon.apache.org.
So I suggest that for now you ignore the newly created files when
website is re-generated.
Someone (me, the authors, or someone else) has to go through these
files, and decide on the following:
1. do they describe something that is part of the next upcoming 2.1.X
release?
- Yes: add them to the navigation menu in the "legacy documentation" at
an appropriate place and give them a "name" in that menu.
- No: see next step.
2. do they describe something that is part of the next 2.2/3.0 release?
- Yes: make sure they are part of the "official documentation" collection.
- No: see next step.
3. are they random thoughts, wild ideas, parking places for unfinished
things?
- Yes: mark them as such, they should not be exported as documentation
- No: should it really be there? Can't it be deleted?
That leaves us with the decision on the navigation structure of the
2.2/3.0 documentation. It was already decided that the navigation in
Daisy should be targeted towards editors (i.e. simplify their work),
while the "official" navigation could be entirely different. Maybe we
should use the Daisy books definition for the navigation structure of
the website to take advantage of the query-based navigation
possibilities (or are they not present in books definitions?).
HTH.
Bye, Helma
