Notes from DAS/2 code sprint #3, day two, 15 Aug 2006 $Id: das2-teleconf-2006-08-15.txt,v 1.1 2006/08/15 19:10:02 sac Exp $ Note taker: Steve Chervitz Attendees: Affy: Steve Chervitz, Ed E., Gregg Helt CSHL: Lincoln Stein, Scott Cain Dalke Scientific: Andrew Dalke UCLA: Allen Day, Brian O'Connor Action items are flagged with '[A]'. These notes are checked into the biodas.org CVS repository at das/das2/notes/2006. Instructions on how to access this repository are at http://biodas.org DISCLAIMER: The note taker aims for completeness and accuracy, but these goals are not always achievable, given the desire to get the notes out with a rapid turnaround. So don't consider these notes as complete minutes from the meeting, but rather abbreviated, summarized versions of what was discussed. There may be errors of commission and omission. Participants are welcome to post comments and/or corrections to these as they see fit. Topic: Spec updates ------------------- ad: made changes to the writeback spec. nothing serious, stuff we talked about. removed possibility of writeback for types, updated docs. returns back a features document. feature element contains old_uri to refer to previous uri if it changed. Not for a response document. gh: can we freeze it at this point? Like the idea of reusing the feature xml. Hoping to call it frozen for rest of code sprint. ad: do we allow relative urls inside the writeback doc. relative to what? gh: xml:base applies ad: if url is still relative once you get to the top of the document, what happens? gh: free to throw an error ad: so 'application defined'. seems ok. gh: can uri's be local when curation is created on client, you're making up your own id. fully resolvable. ad: it is das_private uri, not a relative uri, no resolvability requirements. aday: order of operations issue with insertion and deletions for features with same id. do a delete-insert or insert-delete? does delete get processed before insert? ad: all deletes go first. aday: are all features required to be processed from top to bottom as well? ad: doesn't specify. aday: natural ordering in the document for feature processing. on creation of a new feature. if it has a das_private feature that is declared in the doc which hasn't been seen before. will cause problems. ad: pref aday: require features to be declared in order so that everything declared below refers to things declared above. ad: not possible for new features. aday: where is type writeback going to go? ad: not to be supported. could use a separate document. gh: fine with not dealing with types now. let's get feature writeback going first. aday: would like to make it extensible. to see how you could create a types writeback. gh: separate document. aday: so writeback for types is a element enclosed in a writeback element. gh: any other issues with writeback spec yesterday? many conversations here after the teleconf. the order of operations thing, and the need to freeze ASAP. ad: b gilman's use of VERSION in two diff places. see my email from yesterday. I proposed using 'release' than 'versioned_source'. too late now to change the versioned element. gh: change name of att Topic: Versioned source -> release --------------------------------- See andrew's email from yesterday. aday: has a working server. will send out url out today, after incorporating latest developments. returns a mapping document. gh: will clean up curation stuff today. figure out how to swap ids out. this is an igb internal release. Topic: Microdeltas ------------------ ad: microdeltas: take the delta of the document we have now, break it up into lots of parts. no big two-hour curation, but server tracks changes as they occur. this way you can track reasons for each change. gh: so curator should push 'save to server' button each time they make an edit. this is up to client to impose this. you have a comment element in the writeback. ad: there is a distinction between changes that computer made vs. human comment - reason why they did a whole set of changes. not sure the reason the resolution. gh: microdeltas might be getting a little more complicated for what we're trying to do. Topic: Coordinates in read spec -------------------------------- gh: questions regarding read. Is allen serving up coordinate stuff? aday: segment coordinate uri? gh: the thing we're supposed to be using to decide whether annotations from two servers are on the same coord system. if uri's for two different versioned_sources match, assume they're the same coord system. lincoln set up names for genomes. gh: haven't implemented part on client that makes use of it. currently using a hard-wired way. ad: on open-bio.org site. wiki. gh: writable nature of server is supposed to be in capabilities section. OK you've got in right place. my bad. gh: locking, not worked on. aday: exclusive lock on table to be modified. other clients wanting to write cannot get it. so it's under the hood, no special reponse. ad: how do we indicate a server supports writeback? I wanted an extension tag, not attribute. haven't looked at recently. gh: can't remember. can a versioned_source have... If a versioned source is writable, can any data on that be editable? yes. ad: why does it make a difference. gh: concerned whether there are certain types of annots that should not be writable, level of distinction (granularity). either you can edit any annotations on that versioned source, or none of them. gh: eg. blast results vs human-made curations. can't edit blast results. ad: I don't thing a single bit flag is good enough. gh: per type? ad: not sure. gh: ok as is. you can have multiple servers, some holding mutable data some holding immutable data. ad: I support writing for some people, some time. user is in charge of figuring out which types on which servers can be changed. gh: client has to be smart -- ie., try to edit then undo it then tell user they can edit. or allow user to edit stuff and find out at commit time if editing is ok (possibly not). ad: ideally would like a way to figure out from server what you can and cannot do on a given versioned source. gh: let's not get into that now. that is the simplest way to go w/r/t to the spec. Topic: Viewing das2xml responses in web browser ----------------------------------------------- See Ann Loraine's email on list about trouble of looking at das2 responses via IE4 and Safari. ee: needs text/xml in order to see it in browsers. ad: viewing xml documents is an extension of das, which was intended for computer communication. aday: some problems with javascript/AJAX making it unusable. must have content-type as text/xml. ad: javascript talking to server can specify what format it wants it back. there's a firefox bug in the '+xml' specification. gh: we are telling it xml, it's aday: there are real clients out there that cannot deal with the advance http headers we are using. ad: format= in query parameter gh: format=xml then content-type in header should be text/xml? ad: not in the spec now. you specify das2xml and get back application/.... bo: could have proxy code that sits in between client and server and convers to text/xml ad: default for web browsers. server could decide to support ajax by allowing format=json. aday: gh: need to say that servers have the option to provide content-type=text/xml if format=xml. we are compliant to content-header spec, some ajax implementations don't handle it properly. ad: if client makes request and string text/xml appears in the accepts header, then server should be free to give back regular das2xml response document but as content-type text/xml? by 'free', meaning not required. gh: some libraries are not compliant with http header content type spec. if servers supports that, then they can return different content types. ad: what is recommendation for this case? aday: for firefox and javascript clients. sc: I have had no trouble with firefox on os x. I can try to troubleshoot Ann's set up. Topic: Dasypus online validation tool -------------------------------------- bo: dasypus validation tool is it up to date? ad: server is down since it hasn't been used for a while. should be up to date. [A] andrew will bring dasypus online validator online. Status Reports --------------- bo: bugfixes on das.biopackages.net server. gh: write back curations, id resolution on client side, igb release today. aday: update/edit/delete, changing response type today ad: relaxNG, getting dasypus server back up, my own das server. ee: getting igb release out today. gff3 parser. sc: working with gregg's new Bprobe1Parser to create new versions of exon array data files, more memory efficient. Will send to gregg for testing. Also updating list of available data on the affy das servers.