Damian Smedley wrote:
On Mon, 24 Jul 2006, Tom Oinn wrote:
Damian Smedley wrote:
What is the usual approach taken in webservices to keep track of name
changes in external software? Presumably just hoping people don't change
them is not the approach being taken as that is doomed to failure. Is
there some sort of format to represent the old->new name mappings that
people typically use?
There isn't a way of coping with it, if the names / schema / signature
of methods etc change you're screwed as a client. There's no reason I
can see for the internal names to change anyway, the user visible names
haven't changed so in this case it seems entirely unwarranted, who does
it help?
it was to help people using the API directly in scripts or through their
own Query XML rather than a nice GUI like Taverna. These all use the
internalNames of attributes and filters so it helps if they match the
displayNames (with underscores instead of spaces etc)
Fair enough although it would make sense to have APIs which allowed for
this sensibly rather than changing the metadata itself to suit, more
work though.
I know it's not a property of biomart as such, it's a property of the
way biomart is used but it's still an important point - we now have
clients which can store queries, those stored queries should be made as
stable as possible. There is nothing we can do about this, if we have a
query stored and we try to apply it to the data set after the metadata
has changed the query will be broken, end of story.
hmmm - seems like there should be a way of webservices deployers giving
mappings between versions to support this type of thing. I can't really
see how any sort of storage of queries is going to work, especially in teh
biological community :) We find it hard to maintain stability just within
biomart, if you have a pipeline involving several external resources would
have thought things get unmanagable
They do, yes. Still, things are remarkably stable overall. Issues of
versioning and compatibility assertions are still sadly in the research
domain when it comes to web services. The best you can do is know how
unstable a resource is and that's currently based primarily on
experience rather than any non functional metric available through the
tool itself.
On the plus side, the example workflows that were failing for us are
well over a year old now and still function (once we fixed that glitch)
so with careful selection of your resources it's not hopeless.
Cheers,
Tom
