Forgot the bloody attachment - How many times does one have to put up a message before getting the message through? Oops.
Steve Shattuck's pointed out, quite rightly, that we shouldn't fuss too much over the details of the challenge cases before actually taking the challenges. I think it's important to have a bit of an overview of the challenges for some distance ahead of us while working on one challenge in hand, rather than just taking steps one at a time, because it may be that solving one challenge may canalize us into a solution that makes a challenge down the road more difficult. So I suggest we keep a set of challenges in mind while working. But, of course, it'd be a disaster if we couldn't even agree on the challenges before starting to find the solutions!
Cheers - k
----- Original Message ----- From: "Kevin Thiele" kevin.thiele@BIGPOND.COM To: TDWG-SDD@USOBI.ORG Sent: Sunday, November 25, 2001 9:27 PM Subject: Challenge Cases
| Welcome back! | | I actually posted this message a week ago, but my email address has changed | slightly, and the list server rejected me. So here it is again. | | At the Sydney TDWG meeting we agreed that we would continue with the SDD | discussion on this list, but try to keep a tighter focus. The last active | period (about 12 months ago) was an important brainstorm session, but didn't | seem to be very effective at actually getting us to the goal of a workable | standard. | | We decided this time to try working through some challenge cases - real or | made-up instances of descriptive data that need to be accommodated in the | standard. By agreeing first on a +/- complete set of challenges, then | working through the challenge cases in order from simple to difficult, we | should be able to reasonably bound our problem while keeping an overview of | the territory while actually sinking out teeth into the nitty-gritty. | | Attached is my first attempt at a set of challenge cases, presented in +/- | this form to the Sydney meeting. The first challenge case has an exemplar, | the others have not yet. This document as it's worked up will be placed on | the TDWG web site for working reference. As the standard evolves, this will | also be put up on the site, possibly with progressive status indicators for | parts of the standard (e.g. working, proposed, normative - may we one day | get to normative) | | I suggest that we should first add to or modify the list of challenges. | Propose a challenge (with exemplar) to add to the list. Once we are happy | with an approximate list of challenges (keeping in mind that others will | become clear as we proceed, so there's no need to agonise over this step), | we'll start with challenge 1. We'll throw up the challenge, give a week or | so for contributors to propose data structures that can meet the challenge, | then compare and discuss alternate solutions. | | Gregor I think will shortly be posting a summary of the meeting discussions. | We agreed, I believe, that the goal is to provide a standard that can | adequately address the descriptive data requirements (ie be a superset) of | all existing programs (e.g. Lucid, DELTA, DELTA Access, Biolink) but not be | limited to existing programs. It should be able to function as an | interchange standard, but should not be limited to that. Bob Morris agreed | to provide shortly a discussion on interchange vs interoperability standards | and conflicts that may arise in trying to allow for both goals. We agreed | that XML will be the basis for the standard. | | May the force be with us! | | Cheers - k