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@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@CS.UMB.EDU To: TDWG-SDD@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@bigpond.com To: TDWG-SDD@usobi.org Subject: Re: Challenge 1
----- Original Message ----- From: "Jim Croft" jrc@ANBG.GOV.AU To: TDWG-SDD@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
participants (1)
-
Cornelia Buchen-Osmond