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