Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
> > Bernhard Huber wrote:
> i think writing a single packages.xml is better than maintaing 84
> package.html files.
> >>>
> >>> IMO, a centralized XML file may not be better as far as keeping it up
> >>> to date is concerned :
> >>> - peo
Sylvain Wallez wrote:
> David Crossley wrote:
>
> >There is one important reason for having separate
> >package.xml next to the component source code ... when
> >Cocoon is able to add new components (blocks?) automatically.
>
> Can you elaborate more on this ? As far as I understand them (they're
Sylvain Wallez wrote:
Bernhard Huber wrote:
hi,
i think writing a single packages.xml is better than maintaing 84
package.html files.
IMO, a centralized XML file may not be better as far as keeping it up
to date is concerned :
- people may often forget to update a central file far away fr
David Crossley wrote:
Sylvain Wallez wrote:
Bernhard Huber wrote:
i think writing a single packages.xml is better than maintaing
84 package.html files.
IMO, a centralized XML file may not be better as far as keeping
it up to date is concerned :
- people may often forget to upda
Sylvain Wallez wrote:
>Bernhard Huber wrote:
>> i think writing a single packages.xml is better than maintaing
>> 84 package.html files.
>
> IMO, a centralized XML file may not be better as far as keeping
> it up to date is concerned :
> - people may often forget to update a central file far away
Bernhard Huber wrote:
hi,
i think writing a single packages.xml is better than maintaing 84
package.html files.
IMO, a centralized XML file may not be better as far as keeping it up
to date is concerned :
- people may often forget to update a central file far away from the
source files.
-
On Wednesday 25 December 2002 10:05, you wrote:
> somehow it comes down to question who will most likely write the
> package docs.
> Programmers? than package.html is better
> NonProgrammers, or NotOriginalProgrammers than package.xml is better.
You can have both, provided you sit down and write a
hi,
* add a packages.dtd ala faq.dtd
Yes, it is good to constrain the content.
How much constraint is suitable? Perhaps faq.dtd
is too loose, e.g. it allows ...
On the other hand, perhaps we should not try to
pre-determine the content model.
Hmm, i think we should reuse as much document-v
hi,
i think writing a single packages.xml is better than maintaing 84
package.html files.
IMO, a centralized XML file may not be better as far as keeping it up to
date is concerned :
- people may often forget to update a central file far away from the
source files.
- will people really go insi
Bernhard Huber wrote:
hi,
i have read the thread
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102056702426129
again.
i'd like to start it,
i think writing a single packages.xml is better than maintaing 84
package.html files.
IMO, a centralized XML file may not be better as far as keepin
Bernhard Huber wrote:
> hi,
> i have read the thread
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102056702426129
> again.
>
> i'd like to start it,
>
> i think writing a single packages.xml is better than
> maintaining 84 package.html files.
Great. This is a good approach.
> * add a pac
hi,
i have read the thread
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102056702426129
again.
i'd like to start it,
i think writing a single packages.xml is better than maintaing 84
package.html files.
* add a packages.dtd ala faq.dtd
* write a single packages.xml conforming to packages.d
Diana Shannon wrote:
> David Crossley wrote:
> >
>
> A lot of helpful suggestions!
>
> > These are other tasks to be added to the "To Do" list for the
> > general documentation project ...
>
> Clearly a to-do list is the first of *several* management/planning files
> the doc effort needs. Wher
On May 4, 2002, David Crossley wrote:
A lot of helpful suggestions!
> These are other tasks to be added to the "To Do" list for the
> general documentation project ...
Clearly a to-do list is the first of *several* management/planning files
the doc effort needs. Where should it reside? I'm don
I tried using the Javadocs recently to figure out how a certain
component works. I find that Javadocs are a dissapointment
in general. There is one significant thing that is lacking
The front page of Javadocs is the package index. There are
84 packages in Cocoon and only 6 of them have the b
15 matches
Mail list logo
