pcplantdb

[Chad Knepp <pyg@galatea.org>]

Richard Morris writes:
 > >  > The API should *not* implement any particular markup or presentation 
 > > of 
 > >  > data whatsoever.  That is the job of client software and UIs ('front 
 > > ends').
 > 
 > The question here is how to handle embedded hyperlinks in a block of 
 > text. For example the reference question or a relationship. A simple way
 > is to return an xml format text which does have markup, which is fairy 
 > straigthforward for clients to work with (lots of standard tools for 
 > this). The other option is to return some sort of collection object
 > 
 >      results[0] "Here is a "
 >      results[1] (Hyperlink,http://zip.zap.org/)
 >      results[2] " in the middle of a line of text".
 > 
 > this makes me go ugh.

Eden already has an very simple XML (KFML) that consists of a subset
of HTML and includes a <link/> tag that can be any kind of internal or
external link to be handled appropriately by the client.  KFML does
not have a real DTD yet and is completely open to becoming whatever is
needed.

Related but seperate is the fact that the dataset itself is not
currently XML'ized.  For now this just means that [39] will show up
with no context to the casual user.

 > >  > The API *should* provide ways to ask the data engine to
 > >  > perform all the operations we can think of between a client
 > >  > and the data set (and be expandable to those we haven't
 > >  > thought of yet).  For example:
 > 
 > Argh, can make for a very complex server.
 > 
 > A good XML DTD could specify the API in a straight forward way.
 > I've done stuff like this in other projects, and its got lots of 
 > advantages.

I don't agree.  I see the API and the DTD as different things.  The
API shouldn't have anything to do with XML other than the fact that
calls within the API return XML data.  Clients are solely responsible
to render XML as they see fit.

 > Rich

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