[Biophp-dev] Task oriented design approach (was: comments on CVS, XML, and other TLA's)

[biophp-dev@bioinformatics.org]

On Friday 11 April 2003 03:29 am, Dong Gregorio wrote:
> Hello Greg!  Hello Sean!
>
> Just skimmed through your previous mails yet, but off the
> top of my head, let's have this list of "tasks" then.  I
> guess "goal-directed" or "goal-driven" is another phrase
> that capture Sean's idea.
>
> Cheers!
>
> Serge

Ah, yes, much better phrasing, I think - that's exactly what
I'm trying to get at in my bumblingly over-explanatory way :-)

My CURRENT "goal", for example, is to be able to pull up a list
of articles and their summaries from pubmed based on a keyword
search.  From that "task" follows the need for an interface to 
send the query to ESearch (which in turn breaks down to a generic
"query posting" capability and a specific "query generator" for ESearch), 
to parse the result, particularly the returned ID's (though I also want
the "translations" so that I can tell when and how I've chosen
search terms that confuse the database - e.g. the fact that "cheese"
is not only a "substance" but also a "Medical Subject Heading", so if
I'm looking for a "food science" type of article, I'll need to add further
terms if I want to avoid wading through reports about Listeria and E.Coli
contamination...), and a further capability to send these ID's in sequence
to ESummary and retrieve the results from there.

In my case, websites don't enter into it - I'm the sort of wierdo that
would actually LIKE to have a simple command-line script that I can 
invoke should I want to do a quick lookup of a subject that I saw mentioned,
say, in a news article on biospace.com or something.  "Web specific" output
capabilities will get added later when I (or someone else) have a specific
desire to do this for web page display...which will be almost immediately
since that's the "task" that Greg specifically needs it for :-)

(although, in a more "serious" discussion vein - should the web-format output
be part of an "extended" class, or folded into the "core" class along with
"plain text" output functions?...)

In an ABSTRACT way, I recognize that at some point we'll want, for
example, and interface to the "EPost" capabilities, but in my opinion, 
it shouldn't even be considered until someone has an actual use for it
that they want to program towards.