[Biocorba-l] Re: Biocorba IDL

[Alan Robinson]

On Fri, 20 Oct 2000, Ewan Birney wrote:

> I'm ... hmm ... removing the enum in favour of the string. Neutral.

Hmmmm... I'd prefer const short's over enums or strings:

 - Enums cannot be extended in the future without breaking existing CORBA
   clients. 
 - Strings allow too much freedom, i.e. "Dna", "DNA", "dna", etc.

I favour defining:

     const short PROTEIN = 1;
     const short DNA = 2;
     const short RNA = 3;

By this method, you can add more values to the IDL used by the server, but
exising clients will not break (c.f. enums).

E.g. we can add later:

     const short XXX = 0;
     const short CIRCULAR_DNA = 4;
     const short CIRCULAR_RNA = 5;


> Alan and Matt - did you come down to a vote on the sub seqfeature
> thing?

Not yet... This is a thorny issue.

A complete solution will be necessarily complex, c.f.  the EMBL object
model with separate location objects (e.g. 1..100, 1.2..<30, etc.) and
operator objects (e.g. join, complement, one-of, etc) and a tree structure
that is used to define the relationship between these. 

Of Ewan's proposed solution's, I find (a) closer to the EMBL solution
[where we use structs for the data], but would add we need to have a way
of describing the operations that relate segment locations.

I am unsettled by (d) - E.g. How do you decide which of the SeqFeature
variables and qualifiers are carried through to sub SeqFeatures? I'd
suggest you're mixing up properties of the feature with properties of its
location. That the same feature can have many locations suggests there is
a natural division between these that should be reflected in an object
model of separate feature and location objects.


***HOWEVER!!!*** I understood that the foremost ambition of Biocorba was
to provide *simple and useable* interoperation between the bio* projects,
not define the perfect object model.

To be honest, for the time being I'm happy to go with the pragmatic
approach of start() and end() returning the extremities of the feature
location, and adding a new "getLocationString()" method as a visual sanity
check.

N.B. This isn't laziness, since EBI's already implemented an IDL Feature
Location definition. I could even go with the _span approach (and catch
easily the problem cases of Brad's intronless CDS features).


> BTW - I think the bioperl way of doing it (flattening it and then 
> putting _span on the top one) is bad. I am fully responsible for that
> decision. Ugh. Stupid Ewan!. so -1 for the current behaviour!

Well, you said it ;)


cheers,
al