Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] DTD 0.001

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: john@eco-living.net, Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Cc:
  • Subject: Re: [pcplantdb] DTD 0.001
  • Date: Tue, 25 Jan 2005 13:56:44 -0600

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")'




Archive powered by MHonArc 2.6.24.

Top of Page