[DAS2] Notes from DAS/2 code sprint #3, day two, 15 Aug 2006

Tue Aug 15 19:11:33 UTC 2006

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 <types> 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.