forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruedi Anneler - A-R-T GmbH, Switzerland" <...@a-r-t.ch>
Subject Re: Project Deliverables List ?
Date Thu, 13 Jun 2002 12:31:21 GMT
Steven
thank you for your quick and useful feedback. I'll change the drawing 
accordingly.
I'll
-remove CMD/GUI separation by "editing". I've separated it as GUI tools 
like XML Authority, XML Spy, XMetaL and other can be a big help to 
"isolate" authors from learning/knowing XML tags.
-have a closer look on forrest.xgump and try to implement it (according 
to my understanding)
-try to include other future data sources (as far as understood)

Generic names
The graphic is a high level navigation chart showing logical components 
and their connections. It's an attempt to show the whole thing in a 
logical context allowing people to position themselves and to pick 
information to a certain component they are interested in. This includes 
the physical implementation/tools used for a specific component (it's an 
open community). So I'm trying to use first (generic) logical component 
names instead of physical names describing what a component is and 
contains. In both cases what a component is, does, and contains can be 
done better in a short text by component. The same is true for the 
arrows (can be numbered) describing interfaces, data and control flows. 
I'll deliver this text after cleaning up the drawing to a correct state 
we all can live with. If there are already names like "cocoon" , 
"forrest" and the like most people know, I'd like to know them (doesn't 
make much sense to invent new ones, doesn't it ?).
p.s. the simple drawing in cocoon showing the separation of the 
components  management, content, logic, and style is very generic, and 
very useful for understanding too.

I've a few questions to this; could you please tell me whether I'm right 
or wrong:
-DDS are developed by forrest
-they are put into one component FORREST REPOSITORY for use by all projects
-CSSs are developed by forrest
-they are put into one component FORREST REPOSITORY for use by all projects
-XSLs / XSLTs are developed by forrest
-they are put into one component FORREST REPOSITORY for shared use by 
all projects
-All projects XML (one or more than one by project) repositories are 
Input for CENTIPEDE
-Forrest XMLs are output of CENTIPEDE
-Forrest XMLs (all projects) are input to COCOON
-HTMLs are output of COCOON
-CSSs are embedded in HTMLs created by COCOON
-Batch COCOON doesn't need any XSPs
-the cron.job is kind of a script containing commands controlling the 
batch execution of CENTIPEDE and FORREST

Question:
what about graphics and pictures?
-formats
-source locations
-moving them through the system
-connecting them to XMLs
-embedding them in web pages

additional information
-who is creating them
-what and how
-formats
-source locations
-input for which component (Centipede, Forrest, Cocoon, anything else)


Could you please let me know your ideas about this? thanx.


As far as I understand FORREST until now:
It is a set of combined technical tools that can be used to create one 
way static web pages from different sources. Its main purpose is to get 
a consistent look and feel for all information published by apache.
Besides the facilities offered by CVS forrest it is not a content or 
knowledge management system in the sense of access control, version 
control, workflows, and ownership and an offer of predefined user 
interfaces for authoring, editing, administration, scheduling, 
publication and removal of content.

Please don't take this as criticism. I'm insisting only on these because 
of the special nature of system documentation. This type of 
documentation underlies constant change and is very different from a 
static text (like a newspaper article) of any kind. Its changes must be 
synchronized with the changes of the system it describes. The easy and 
not too time consuming maintenance and management of the document 
content as a whole and the just-in-time synchronization with the system 
it describes is of main importance for its usefulness. If this cannot be 
done, the documentation system will not deliver the expected benefit and 
 useful results; in the worst case it will not be used by anybody (this 
is proven reality, I've seen it several times).

Toady's technologies (XML and the applications of XML) offer some 
opportunities to do this better than with conventional, hierarchically 
stored documentation (e.g. MS WORD and the like). Documenting the 
"conventional" way is always creating documents consisting of a mixture 
of process, technology and organization descriptions suited to a 
specific users groups needs - very hard to maintain (in reality seldom 
really maintained; often thrown away after a certain time as becoming 
wrong, misleading and useless). I made documentation reviews in project 
of any size and have not seen only one company (with the exception of 
the few pharma, automotive and airplane building industries using huge 
SGML CM installations or the like) really able to handle these problems 
without a content management system. Based on this I'd like and suggest 
to have a closer look how to handle the whole documentation process (aka 
data splitting for storing and easier maintenance, data combination for 
presentation, data flow, workflow and roles as well) before running into 
the same problems with system information documentation maintenance a 
lot of people already had and have.
I'm aware of the fact that nobody can jump several meters high at once 
and without any preparation. The development of such a system is a 
several years lasting evolutionary process. But as most projects and 
companies had and have severe problems in this area, it's probably worth 
to at least begin with something addressing these burning needs ...

I'll post this on the list again, of course. A changed/corrected version 
of the my initial drawing follows soon.

Take care and have a good day,
Ruedi


Recently I've found this in an advertisement for BMW motorcycles (and 
attacking the japanese ones):
"It is not a real improvement to ride faster every day in the wrong 
direction."

hope you like it :-D .


Steven Noels wrote:

> Ruedi,
>
> I don't have much time today - please find some scribbling attached
>
> i think it is better to continue this discussion on the list
>
> regards,
>
> </Steven>
>
> ------------------------------------------------------------------------
>
> <cid:part1.00070601.09070209@netscape.com>
>


Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message