pcplantdb

[John Schinnerer <john@eco-living.net>]

Aloha,

> I'm not sure if an XML DTD is the right way to approach this. Mainly 
> because its hard to understand for lay people.

IMO an XML DTD will be a part of formal specs - specifically, it will be 
the spec for XML markup to be used however we end up using XML markup in 
the project.

Definitely not a primary spec document.

That should be in as plain as possible English...a functional spec 
stating in chunks and steps and substeps what the product will do.

Chunk 0: database
  The database will be/do...(high level statement(s) - HLS hereafter - 
of what it will do)
    HLS1 will be accomplished by...(details of HLS1)
    HLS2 will be accomplished by...(details of HLS1)
    And so on...


Chunk 1: data engine
  The data engine will be/do...(high level statement(s) - HLS hereafter 
- of what it will do)
    HLS1 will be accomplished by...(details of HLS1)
    HLS2 will be accomplished by...(details of HLS1)
    And so on...

Chunk 2: data transport
  Data transport will be accomplished by/with...(HLS(s) on data transport)
    HLS1 wil be....etc. as above, the XML DTD goes in here somewhere

Chunk 3: User interface (initial/dev/test)
  The user interface will provide/do...(high level statement(s) - HLS 
hereafter - of what it will do)
    HLS1 will be accomplished by...(details of HLS1)
    HLS2 will be accomplished by...(details of HLS1)
    And so on...

Each HLS1 may have substatements that break down into smaller steps.

Smallest steps should describe each function at a level of detail 
adequate to code from without having to make any significant/non-trivial 
assumptions.

Can be written with word processor using outline formatting; some people 
like to use spreadsheet.

If done this way it becomes a "good enough" functional test spec also.

> A post by Heidi on piw suggested a way that we might proceed.
>
> > Then really what remains to be decided is
> > - what criteria we want to report
> > - how we want to label them
> > - how we want to report them (plain text etc.)
> > - how we want to search them
>
>
> A few questions like this, suitably broken down, could start the 
> process. Then we can find solutions to these questions and if necessary
> break the questions down. Once we are there we can translate to a 
> database schema or XML DTD.

Yep!!

> I'm also thinking that the bug tracker could be used to focus our 
> decision making. I've not had a look at the specific software John S+H 
> are investigating, but if its like bugzilla we have some useful features
> 1) Ability to prioritise tasks
> 2) A means to assign tasks to people.

Yes, will have both of those.
As mentioned, it is my #1 PIW task, and will still be a week or so 
realistically.  Gotta get the roof on!

> Task no 1 could be "produce formal spec."
>
> Task 2: Devlope key questions.
> Heidi has nicely identified some
>
> Q2 - what criteria do we want to report?
> Q3 - how do we lable them?
> Q4 - how do we report them?
> Q5 - how do we search them?
>
> I'd also add:
>
> Q1 - what objects do we want to record data about?
>     (not necessarily just plants, also have cultivars,
>     families & higher order taxa, locales etc.)
> Q6 - what user input is allowed?
>
> We have covered a lot of these questions in an informal manner
> but it is imperitive that we start to converge on some answers.
>
> I think we should start with Q2 for plants for now.
> I'll post a separate post with the answers to some of these.

Agree, sounds good.
Exactly what questions we need to answer will evolve once we get started.

John S.


--

John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net