Challenge 1

[Cornelia Buchen-Osmond]

I don't think that DELTA has given up too soon to "decide
whether ease (as opposed to possibility) of producing documents is a
more important design goal than ease of describing structures suitable
for searching, integration with other structures such as those
emerging from the Accessions groups efforts for specimen records,
molecular data, and other data from sources other than those in a
descriptive database".

When starting with a database you often don't know, what is needed to suit
best the demands.  Text comments are very helpful to get to the first basis
and the developer of the database has to integrate those comments later on
into well structured language that is searchable.

Dr Cornelia Büchen-Osmond
Biosphere 2 Center
32540 S. Biosphere Road
P.O. Box 689
Oracle, AZ 85623
U.S.A.
Phone +1 (520) 896-5126
Fax     +1 (520) 896-6429
email:   buchen at bio2.columbia.edu

ICTVdB - The Universal Virus Database
http://www.ncbi.nlm.nih.gov/ICTVdb/
http://www.ictvdb.iacr.ac.uk/
http://www1.im.ac.cn/ictvdb/welcome.htm

----- Original Message -----
From: "Robert A. (Bob) Morris" <ram at CS.UMB.EDU>
To: <TDWG-SDD at USOBI.ORG>
Sent: Sunday, December 02, 2001 6:55 AM
Subject: Re: Challenge 1


> I don't believe that minimizing markup is a desirable design goal. The
> usual argument for it is that it makes the document easier for humans to
read,
> but the plain fact is that XML is rarely written or read by humans
> except when they are either debugging or designing. If there really
> are no natural tags to surround text in a particular case, it is
> common to just surround it with <text> </text>.
>
> In this case, as is common, the tension arising is that between
> articulating object structure and articulating document structure. As
> I now understand DELTA, it devotes quite a bit of energy to ease of
> producing documents, and maybe this group has to soon decide
> whether ease (as opposed to possibility) of producing documents is a
> more important design goal than ease of describing structures suitable
> for searching, integration with other structures such as those
> emerging from the Accessions groups efforts for specimen records,
> molecular data, and other data from sources other than those in a
> descriptive database. Resolving this tension with a compromise could
> make /both/ enterprises hard instead of just one. My own bias, and I
> think that of XML, is that it is easier to compute documents
> given rigorous structure than the other way round.
>
>
>
> Kevin Thiele writes:
>  > Date:         Sat, 1 Dec 2001 22:12:56 +1100
>  > From: Kevin Thiele <kevin.thiele at bigpond.com>
>  > To: TDWG-SDD at usobi.org
>  > Subject:      Re: Challenge 1
>  >
>  > ----- Original Message -----
>  > From: "Jim Croft" <jrc at ANBG.GOV.AU>
>  > To: <TDWG-SDD at USOBI.ORG>
>  > Sent: Saturday, December 01, 2001 8:30 AM
>  > Subject: Re: Challenge 1
>  >
>  >
>  > | Kevin wrote:
>  > | >I've taken the route of marking up a textual description, using a
minimum
>  > of
>  > | >tags. It seems to me that a description comprises a series of
features
>  > with
>  > | >values. I've used mixed markup because I wanted to have the mimimum
>  > | >tagging and make maximum use of the text.
>  > |
>  > | Although XML allows mixed content such as Kevin's:
>  > | <Feature><Name>spines</Name>, not developing at each node,
>  > | <Feature Name="Length" MinValue="0">to c.
>  > | <MaxValue>1</MaxValue><Units>cm</Units> long</Feature>
>  > | </Feature>
>  > | and such a document can be validated against a schema, apart from
being
>  > | untidy and inelegant, mixed content can pose certain problems when
>  > | attempted to be loaded into a relational database; this is probably
not
>  > | going to impress people like Gregor.
>  > |
>  > | Can we agree that although mixed content XML is quite allowable, we
are
>  > | going to try and avoid it in the SDD context?
>  >
>  >
>  > Hey, who said we should aim to make life easier for Gregor? I regard it
as a
>  > life ambition to make things harder for software developers, especially
>  > those who insist on cramming mother nature kicking and screaming into a
>  > database!
>  >
>  > The mixed content of my suggestion is the thing I worry about most. But
if
>  > there are advantages to mixed content (and it seems to me there are)
then I
>  > think these should be weighed against the difficulty of dealing with
it.
>  > Once we have more alternate solutions to challenge 1 we can deal with
the
>  > advantages/disadvantages of particular solutions. I wouldn't like to
>  > preclude mixed content at this early stage - let's knock it on the head
a
>  > bit further down the track.
>  >
>  > Cheers - k
>  >
>