forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: status.xml versus separate files
Date Mon, 18 Nov 2002 08:01:21 GMT

David Crossley wrote:
> Diana Shannon wrote:
>>What do Forresters prefer?
>>- a single (huge) status.xml for an existing, active project
>>- separate changes.xml, todo.xml, and who.xml files (with edits to a 
>>project's sitemap.xmap)
> I grew up with Cocoon, so i am used to the separate files.
> They have DTDs to control them, so that is good.
> Another reason is that a project can have separate changes
> and todo files at other levels of the project (Cocoon has
> a changes.xml for the top-level and also changes-doc.xml).
> When Forrest started, i was a little concerned that the
> big status.xml would be clumsy, and still am concerned.
> Also this file does not seem to have a DTD/RNG yet and
> new capabilities seem to be added to it.

We need one for status.xml too.
When I did it, I already wanted to add extra sections, so I didn't write 
the DTD yet. When we are confident of the new format, we surely will.

> So i prefer the separate files.
> However, i suspect that there is a good reason for the
> status.xml ... i wonder if it is used by some some other
> project like Gump or such. Also it may be an attempt to
> get a common file used by all projects.

The reasons why I preferred to use one file only is:
  1) it could replace STATUS
  2) it's a single location for community-related stuff
  3) <developers> are referenced in both changes and todos,
     thus I reckoned it better to have them all in the same file

> I am happy to use the centralised status.xml if we can
> find a way to manage its growth. Perhaps regularly archive
> stuff off to status-2002.xml etc. I suppose that the separate
> changes.xml would have the same growth problem.

Basically yes.
If you look at the status files you will find that ATM the problem is in 
the "changes" part, but in the future also the "issues" will grow.

These are possible solutions I see:

  1) make a status.xml that simply references changes.xml, status.xml,
     issues.xml, etc in a ./status folder
     (or ./project or ./community or whatever)
  2) archive all changes in releases previous to the current in a
     ./status changes-archive.xml file
  3) make a graphocal editor to status.xml that makes it easy to
     update regarless the size of it

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message