pcplantdb

[Chad Knepp <pyg@galatea.org>]

John Schinnerer writes:
 > Aloha,
 > 
 >  > Also I think
 > > we need a lot of markup for the various atomic data elements like
 > > height, hardiness, etc, which you touch on with physical and growing
 > > conditions.
 > 
 > Agreed.
 > 
 > > A lot of the rest of the existing data (the text blobs) I would like
 > > to move to a more universal context such as that of a comment.  These
 > > include cultural notes, propagation notes, know hazards, edible uses,
 > > medicinal uses, and other uses.  These could be as individual comments
 > > or grouped together as a single comment by Ken Fern.  This is a point
 > > that needs additional discussion.
 > 
 > How accessible is this info going to be if it's all lumped into a 'more 
 > universal context' such as a comment?
 > What do you mean, in DB and search/retrieve terms, by a comment?

Search a text blob is just as easy as searching a single word.  The
only problem is when non-text data gets mixed in like heights,
temperatures, and references (already in there) and such which can get
lost in a text blob, unless you remember to look for those as well.

Big words that didn't really say what I meant, but by universal
context I meant that I would like to say that many/most things are of
'object type' comment.  Taking Ken Ferns text data, which comprises a
lot of our current dataset, and turning it into comment(s) with which
other comments could be added and attached.

 > > I also want to check in about the time frame of moving to a fully
 > > XML'ized version.  This represents a significant amount of work that
 > > does benefit the development of additional clients but not much else.
 > 
 > I think it would benefit the development of all clients, including our 
 > initial one, and the project as a whole, by:
 > 1) supporting data/logic/presentation separation early on
 > 2) working the kinks out of XMLizing data early on
 > 3) creating and refining an appropriate DTD early on
 > 4) exposing any "gotchas" and/or mistaken assumptions about XMLizing 
 > whatever you're creating now later on, before they might be a real PITA 
 > to deal with.
 > 
 > Mind you I'm no fan of the big overhead of XML for data transport, and, 
 > if we're going to do it let's just do it.

In retrospect, I don't think it would be that hard to really do full
on XML, I just was not seeing a case where it would be utilized for a
bit. 

 > I'm a little dubious of the value of 'shortcuts' that are specific to 
 > our perceived immediate needs.  Will they be of any value to anyone 
 > else?  Will they support alternative clients as fully as XML and/or 
 > XML-RPC, assuming someone chooses to code their client to use the 
 > 'shortcuts'?

I guess there is really only one big shortcut that I had in mind, the
one of creating a readable paragraph of about the plant based on 30-40
different elements from the database.  Compared to having the data
engine look up a plant and doing things like <height system="metric"
units="meters">30</height> for all of the elements, handing it to the
client, and then having the client put it into a paragraph seemd like
unnecessary overhead.  On the other hand making changes to single
elements will need to do this...

 > My $.02 on that...
 > 
 > John S.

-- 
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'