[tcs-lc] Minor modifications prior TDWG ratification vote

[Richard Pyle]

I understand the desire to keep a high threshold for breaking backward
compatibility, but I predict that when we start throwing real-world datasets
at it, we're going to want an enumerated list for Name-Name Relationships,
rather than dedicated elements for each Name-Name Relationship (for the
reasons Gregor listed).

Based on your second paragraph, I would be inclinded to lower the threshold
for v2.0, so that it can be implemented before too many people put too much
effort into developing apps for v1.0.

It's not that I necessarily think 1.00 is bad, or won't work.  But I really
think that when we apply large datasets to it (I plan to dump the Catalog of
Fihses dataset into it before the end of this year), we're going to discover
a whole raft of non-minor changes that we'll want to implement.

Aloha,
Rich

> -----Original Message-----
> From: tcs-lc-bounces at ecoinformatics.org
> [mailto:tcs-lc-bounces at ecoinformatics.org]On Behalf Of Sally Hinchcliffe
> Sent: Tuesday, September 20, 2005 10:09 PM
> To: tcs-lc at ecoinformatics.org
> Subject: Re: [tcs-lc] Minor modifications prior TDWG ratification vote
>
>
> Rich wrote:
> >
> > Sally wrote:
> >
> > > I think we also mentioned at the time that we should
> > > confine these last minute amendments to changes that would otherwise
> > > break backwards compatibility (for example changing element names, or
> > > removing something, or adding a required field).
> >
> > I can certainly understand this constraint in the context of
> "minor" changes
> > to TCS 1.00 before final "lock-in".  However, I do desperately hope that
> > this backward-compatibility constraint will not be imposed on
> changes made
> > for version 2.00.  Backward compatibility is certainly nice, but in this
> > context, I think it would be debilitating....
> >
> I think (again this was talked over at the meeting) that we go from
> 1.0 to 2.0 basically when we break backwards compatibility in some
> form. So it's not impossible (and we're probably going to have to
> break it in some way anyway) but there should be a big threshold of
> need before we break it, and then we should aim to break it once and
> hold off before breaking it again.
> By the time we get to version 2.0 I predict we will have a lot of TCS
> implementations out there in one form or another, including one for
> IPNI, so big changes will be painful and if we keep breaking people's
> implementations then we will not be popular
> That said if we can provide easy XSLT transformations between 1.x and
> 2.0 it might not be too bad
>
> Sally
> *** Sally Hinchcliffe
> *** Computer section, Royal Botanic Gardens, Kew
> *** tel: +44 (0)20 8332 5708
> *** S.Hinchcliffe at rbgkew.org.uk
>
> _______________________________________________
> Tcs-lc mailing list
> Tcs-lc at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/tcs-lc