From dalke at dalkescientific.com Mon Jan 2 11:57:55 2006 From: dalke at dalkescientific.com (Andrew Dalke) Date: Mon, 2 Jan 2006 17:57:55 +0100 Subject: [DAS2] phone conf. call cancelled Message-ID: Gregg mentioned this in mail that didn't make it to the main list. His phone line is down due to extreme weather and his internet connection is flaky. It's a holiday at Affymetrix, and on my side of things I've made only a few updates to the spec and have nothing to talk about. So today's phone conference is canceled. We may reschedule next week's call because Lincoln can't make the normal time. And a Happy New 2006 to you all. Andrew dalke at dalkescientific.com From Gregg_Helt at affymetrix.com Mon Jan 2 12:02:20 2006 From: Gregg_Helt at affymetrix.com (Helt,Gregg) Date: Mon, 2 Jan 2006 09:02:20 -0800 Subject: [DAS2] Today's DAS/2 teleconference cancelled Message-ID: Today's DAS/2 teleconference is cancelled. Let's resume again next week. Apologies for the late notice... thanks, gregg From td2 at sanger.ac.uk Thu Jan 5 06:27:31 2006 From: td2 at sanger.ac.uk (Thomas Down) Date: Thu, 5 Jan 2006 11:27:31 +0000 Subject: [DAS2] Code sprint Message-ID: <0AEA6B9E-4A0A-4171-B96A-64F8041CC1C8@sanger.ac.uk> Following on from e-mail and teleconference discussions before the holidays, there seems to be fairly widespread agreement that having some kind of Code-sprint/Hackathon/whatever to get some more implementations up and running would be a Good Thing. But was there ever an agreement on dates and locations? On a related issue, what's the current status of the spec in CVS? It would be nice to have an agreed version we could all read and digest before the code sprint, in the hope that we'll all implement the same thing. Thomas. From dalke at dalkescientific.com Thu Jan 5 07:37:22 2006 From: dalke at dalkescientific.com (Andrew Dalke) Date: Thu, 5 Jan 2006 14:37:22 +0200 Subject: [DAS2] Code sprint In-Reply-To: <0AEA6B9E-4A0A-4171-B96A-64F8041CC1C8@sanger.ac.uk> References: <0AEA6B9E-4A0A-4171-B96A-64F8041CC1C8@sanger.ac.uk> Message-ID: <1f845ea05d26e32213d0e589e3c199a6@dalkescientific.com> > But was there ever an agreement on dates and locations? Yes. At least for one of them. I took notes but never wrote it up. I'll dig around to find it. The final idea was to have two sprints, one in the UK on 6-10 of February and another in California some time in the latter part of March. Anyone can be involved, and I expect there to be a phone conference call to talk about things for those who are not local. > On a related issue, what's the current status of the spec in CVS? It > would be nice to have an agreed version we could all read and digest > before the code sprint, in the hope that we'll all implement the same > thing. I've been working on updating the spec but it's slow going. Nor is that progress in CVS. I can change that but currently my internet access is (somewhat deliberately) spotty. Andrew dalke at dalkescientific.com From gilmanb at pantherinformatics.com Thu Jan 5 08:10:09 2006 From: gilmanb at pantherinformatics.com (Brian Gilman) Date: Thu, 5 Jan 2006 08:10:09 -0500 Subject: [DAS2] DAS 2 Code? In-Reply-To: <1f845ea05d26e32213d0e589e3c199a6@dalkescientific.com> References: <0AEA6B9E-4A0A-4171-B96A-64F8041CC1C8@sanger.ac.uk> <1f845ea05d26e32213d0e589e3c199a6@dalkescientific.com> Message-ID: Hello Everyone, We're ramping up now and would like to get our hands dirty with the reference implementation. Can someone point us at the cvs repo? Thanks in advance, Brian -- Brian Gilman President Panther Informatics Inc. E-Mail: gilmanb at pantherinformatics.com gilmanb at jforge.net AIM: gilmanb1 01000010 01101001 01101111 01001001 01101110 01100110 01101111 01110010 01101101 01100001 01110100 01101001 01100011 01101001 01100001 01101110 On Jan 5, 2006, at 7:37 AM, Andrew Dalke wrote: >> But was there ever an agreement on dates and locations? > > Yes. At least for one of them. I took notes but never wrote > it up. I'll dig around to find it. > > The final idea was to have two sprints, one in the UK on > 6-10 of February and another in California some time in the > latter part of March. > > Anyone can be involved, and I expect there to be a phone > conference call to talk about things for those who are not > local. > >> On a related issue, what's the current status of the spec in CVS? >> It would be nice to have an agreed version we could all read and >> digest before the code sprint, in the hope that we'll all >> implement the same thing. > > I've been working on updating the spec but it's slow going. > Nor is that progress in CVS. I can change that but currently my > internet access is (somewhat deliberately) spotty. > > > Andrew > dalke at dalkescientific.com > > _______________________________________________ > DAS2 mailing list > DAS2 at portal.open-bio.org > http://portal.open-bio.org/mailman/listinfo/das2 > From nomi at fruitfly.org Thu Jan 5 20:09:16 2006 From: nomi at fruitfly.org (Nomi Harris) Date: Thu, 05 Jan 2006 17:09:16 -0800 Subject: [DAS2] A publically accessible DAS/2 server implementation Message-ID: dear das/2 people, i am about to start implementing a das/2 reader for apollo. obviously, i will need a das/2 server to test it with. i went to http://www.biodas.org/ and clicked on "A publically accessible DAS/2 server implementation" and it brought me to an empty page (http://das.biopackages.net/das/genome). is this an issue with my browser (i'm using mozilla on linux) or is something else wrong? thanks, Nomi From allenday at ucla.edu Thu Jan 5 20:53:15 2006 From: allenday at ucla.edu (Allen Day) Date: Thu, 5 Jan 2006 17:53:15 -0800 (PST) Subject: [DAS2] A publically accessible DAS/2 server implementation In-Reply-To: References: Message-ID: It won't show up in your browser, try using a command line utility like GET / wget / curl. -Allen On Thu, 5 Jan 2006, Nomi Harris wrote: > dear das/2 people, > > i am about to start implementing a das/2 reader for apollo. obviously, i > will need a das/2 server to test it with. i went to > http://www.biodas.org/ and clicked on "A publically accessible DAS/2 > server implementation" and it brought me to an empty page > (http://das.biopackages.net/das/genome). is this an issue with my > browser (i'm using mozilla on linux) or is something else wrong? > > thanks, > Nomi > > > _______________________________________________ > DAS2 mailing list > DAS2 at portal.open-bio.org > http://portal.open-bio.org/mailman/listinfo/das2 > From Gregg_Helt at affymetrix.com Mon Jan 9 11:50:46 2006 From: Gregg_Helt at affymetrix.com (Helt,Gregg) Date: Mon, 9 Jan 2006 08:50:46 -0800 Subject: [DAS2] DAS/2 teleconference today Message-ID: We're back to our regular DAS/2 teleconference schedule today at 9:30 Pacific time. I'd like to focus on the upcoming DAS/2 hackathon (in early February?), and whatever we need to do to stabilize the read part of the spec by then. Conference numbers US dialin: 800-531-3250 International dialin: 303-928-2693 ID: 2879055 thanks, gregg From dalke at dalkescientific.com Mon Jan 9 12:31:36 2006 From: dalke at dalkescientific.com (Andrew Dalke) Date: Mon, 9 Jan 2006 19:31:36 +0200 Subject: [DAS2] spec status Message-ID: Hi all, I'm slowly making my way through the spec and integrating the changes but it's taking me a lot longer than I expected. I've been very precise and detailed in what I've said, but as a result it's not very fun work. The current status is in CVS under das/das2/new_spec.txt . It contains the content of what I'm doing and is not formated for HTML. Once it's fleshed out I'll move it into the existing HTML system. I'm nearly done with the background information which describes the different parts of the spec. I'm about to start making the changes in the read part. What I've been working on is the generic header section for the sources document. This is the one Andreas and others wanted, to add server information (eg, email address of the server maintainer). I want to do it like this .. fields go here .. and define a few elements like That got me to wondering about the new property fields we were talking about for the feature records. They were going to look like This is the value or perhaps (I forgot which we decided - I think the latter. I haven't gone through the notes to figure out which and it doesn't matter for this.) The propertyTag was a fully namespaced element, which might look like das2:bgcolor dss:glyph3d where das2 == http://www.biodas.org/... dss == http://www.dalkescientific.com/das-extensions As I recall, the idea was that these fields will be searchable. Specifically, one of the fields was "top-level feature regions" used to replace the /regions information. I've having problems making those fields searchable in a generic sense. There are two problems. 1) need to send the fully qualified element name to the server for search, like {http://www.dalkescientific.com/das-extensions}glyph3d=sphere 2) properties are typed. Is the search for a generic field by substring, by whole word in string, by numeric value (so that "1" == "1.0"). I'm beginning to think it's just not worthwhile having this the properties extensible by element tag name. So I emailed one of the Atom developers. > As to why simple extensions exist; my belief is that they are there as > a sop to the RDF/semantic-web community, who really REALLY wanted to > make Atom an RDF application; the WG wouldn't go for that but was > willing to bless the "simple extension" mechanism, which can > straightforwardly be mapped onto RDF. Okay, time for the phone conference call. Andrew dalke at dalkescientific.com From nomi at fruitfly.org Mon Jan 9 14:00:14 2006 From: nomi at fruitfly.org (Nomi Harris) Date: Mon, 9 Jan 2006 11:00:14 -0800 Subject: [DAS2] Re: Link to GAME XML schema In-Reply-To: References: Message-ID: <17346.45758.386603.260859@spongecake.lbl.gov> On 13 December 2005, Nomi Harris wrote: > http://biodas.org/documents/das2/das2_get.html has a link to > http://flybase.net/annot/gamexml.dtd.txt for GAME XML documentation. > This link should be changed to > http://flybase.bio.indiana.edu/annot/game.rng.txt > > Thanks, > Nomi This link hasn't been changed yet. If someone wants to give me access to the biodas web server, I'd be happy to change it myself. Nomi From Steve_Chervitz at affymetrix.com Mon Jan 9 14:27:53 2006 From: Steve_Chervitz at affymetrix.com (Chervitz, Steve) Date: Mon, 9 Jan 2006 11:27:53 -0800 Subject: [DAS2] DAS/2 weekly meeting notes for 9 Jan 2006 Message-ID: Notes from the weekly DAS/2 teleconference, 9 Jan 2006. $Id: das2-teleconf-2006-01-09.txt,v 1.1 2006/01/09 19:32:33 sac Exp $ Note taker: Steve Chervitz Attendees: Affy: Steve Chervitz, Ed E., Gregg Helt Sanger: Andreas Prlic Sweden: Andrew Dalke UC Berkeley: Suzi Lewis Action items are flagged with '[A]'. These notes are checked into the biodas.org CVS repository at das/das2/notes/2005. 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. Today's topic: Planning for Code Sprint ---------------------------------------- Agenda: Focus on the upcoming DAS/2 code sprint in early February in the the UK and whatever we need to do to stabilize the read part of the spec by then. GH: Andrew proposed in the UK early feb, and in the US later March. Getting people from the US to the UK can't do. There's no funding for it. Can teleconf into the UK from US. Maybe get together Bay area people (suzi, nomi, gregg, ed, steve). Would also be good to get Allen Day involved. Terminology note: 'code sprint' is preferred to 'hackathon'. AD: The dates for the UK code sprint are 7-11 of Feb. Have already schedule flights. In the US, march sometime but it has not been determined. GH: Will UK people be able to get their schedules cleared to dedicate a solid block of time? I can do so here in the US. AD: Planning to spend the whole time on the code sprint. AP: would be able to attend, planning to write an announcement, registration mechanism, reserve a room, and start coding... [A] Andreas will post announcement for Feb code sprint, set up registration form, reserve room SL: I will notify Nomi about it today. When is the progress report for the grant review due? GH: Not sure. Sent one in may/june last year. SL: Important to send report before review committee sits. Would be good to report on the code sprint for the review. GH: Received notice at end of last year that renewal has been received. Initial peer review will be done by end of march 2006. funding decision after May 2006. So we could for sure get in a write up on the UK, and possibly the US one to. Assigned group: "center for scientific review, special emphasis panel" (not the same group as last time, unfortunately). [A] Gregg will prepare reports of code sprint results before grant review GH: What do we want to accomplish when we have one week to do it? SL: DAS/2 adaptor for apollo. GH: - Make IGB code for DAS/2 client, update to reflect changes in spec implement unimplemented stuff. - DAS/2 server at Affy - bring it up to the spec as well. not a full impl but was compliant 3 mos ago. AD: Three things: - make sure spec works for people providing DAS/2 gets. - write up the writeback stuff. - work on validator. Steve: - brainstorm test cases for validator. - testing compliance as well as performance - more spec work possibly? AP: - Would like to work on the registry. - Serving real data with DAS/2. - Thomas is also planning to be involved. AD: been updating the spec to include all the things discussed in the past month. Want to get it updated at least a week before the code sprint. Slow at text writing since prefers coding. It's really boring to do this. Easy to get distracted. GH: Would also like to get Allen Day to sign on for updating the chado-based DAS/2 server, bringing it on with latest changes. Possibly get him to come up with the others in the west-coast. Haven't contacted him yet. SL: Can't do it (in Philly). Mark can't either, but likely can be involved in the March sprint. GH: March sprint, anytime in the middle 3 weeks of march. AD: will be at a san diego workshop in march. Back in the states in Mid feb. SC: There is a MAGE v2 workshop/jamboree in Benecia, CA on 7-11 March. Should probably aim for later March. Also will be involved in a netaffx quarterly update. GH: We could spend time on Netaffx-related stuff during the DAS/2 code sprint in March. E.g., pipeling the data prep for the netaffx DAS/2 server. GH: Other two groups to ping for involvement: - NCI stuff that Brian Gilman is doing (see his post to list - ready to start going). - UCSC - DAS/2 annot server. they're not budgetted until the renewal, but could get started. Who from UCSC? will have to look at notes. someone whose worked on the DAS/1 server. GH: Any more ideas for the format of the code sprint? AD: wait until we get closer to the date. SL: Need clearly defined goals. too many things could be going on. Put this together closer to the date. SC: Yes, would be good to have defined deliverables. Some way of measuring success. [A] Someone will write up goals for the Feb code sprint. AP: Want to write an official invitation to the list, invite people to register and say what they are planning to work on, and would like to work on. AD: Planning to put more spec additions. Searching for features. query now is set up via params on url. wants the props to have key val = key is the xml element name and the value is the value. But how to get this to work with how we do queries...How you'd put it into the query url -- element name is the fully qualified thing. How would this interact with the search for properties in spec now, the name of property is a short 6-char thing, not a long url thing. also some props are numbers, is you search for 1 does it match 1.0? GH: the property id is now a long URI. this is the problem. AD: emailed an atom spec developer to ask. said: it's a sop (?) to the rdf semantic web community. People who wanted rdf wanted to use that field. So maybe just prop name=.. value=... where name is anything. SL: can we use 'tag' or 'key' instead of name? AD: was reading an article/news group: names and cache coherency are the only really hard things in comp programming. GH: So now for an arb prop in a feat, it would be AD: query spec now uses colon (attr:) GH: feat filters att=property:value - implies that you can't have a colon in the property AD: likes idea of colons for namespaces, but dots could work. Also, some fields are strings, ints, float, etc., and searches mean different things for different property keys. Better to have partial solution and not strive for full genericity. GH: hasn't been impl in client or server yet (property types). AD: corba/ soap allow clients to ask servers what they support. rarely see this actually being used. So best not to put too much work into it. SC: Would key make use of URI base? I.e., be implicitly a URI? AD: no just a string e.g., 'bgcolor'. GH: like what we do now in types where we have a uri as an id and you can short hand the uri AD: if we want one we can stick one in the properties table GH: can use it if we need to later. GH: So we're set then for the 6-11 feb . From nomi at fruitfly.org Mon Jan 9 15:06:08 2006 From: nomi at fruitfly.org (Nomi Harris) Date: Mon, 9 Jan 2006 12:06:08 -0800 Subject: [DAS2] DAS/2 weekly meeting notes for 9 Jan 2006 In-Reply-To: References: Message-ID: <17346.49712.576001.115347@spongecake.lbl.gov> On 9 January 2006, Chervitz, Steve wrote: > Notes from the weekly DAS/2 teleconference, 9 Jan 2006. thanks for sending these detailed notes, steve. i'm a little confused, reading the notes, about what the final decision was about the code sprint. there's going to be one in the UK, feb 6-11, and then one in california, some time in march? when? once we have dates, i'd be happy to help with planning (e.g. housing and meeting rooms) if needed. > [A] Andreas will post announcement for Feb code sprint, set up registration > form, reserve room > > SL: I will notify Nomi about it today. When is the progress report for > the grant review due? what do i need to do in terms of participating in this? obviously, i won't be going to england for it. will we be scheduling extra teleconferences, or F2F meetings with bay-area people, or what? > GH: Not sure. Sent one in may/june last year. > > SL: Important to send report before review committee sits. Would be > good to report on the code sprint for the review. > GH: What do we want to accomplish when we have one week to do it? > > SL: DAS/2 adaptor for apollo. i am already starting work on this--should i stop? initially, i've been trying to construct arguments to the the DAS/2 server at http://das.biopackages.net/das/genome to get some sample features (using http://www.biodas.org/documents/das2/das2_get.html#features as my reference). > GH: > - Make IGB code for DAS/2 client, update to reflect changes in spec > implement unimplemented stuff. IGB already has a DAS/2 client, right? the comma is confusing me--are you just saying the IGB DAS/2 client code needs to be updated and extended? > - DAS/2 server at Affy - bring it up to the spec as well. not a full > impl but was compliant 3 mos ago. is that http://das.biopackages.net/das/genome? > GH: March sprint, anytime in the middle 3 weeks of march. > > AD: will be at a san diego workshop in march. Back in the states > in Mid feb. > > SC: There is a MAGE v2 workshop/jamboree in Benecia, CA on 7-11 > March. Should probably aim for later March. Also will be involved in a > netaffx quarterly update. the CBIO project meeting is march 2-4. i will be away march 23-26 (trip planned long ago). are a lot of people going to participate in this MAGE workshop? maybe it would work well to have the code sprint right after it, say, march 13-19? i don't think we want to make it any later than that or there won't be time to write it up for the progress report. in fact, that might already be too late. Nomi From nomi at fruitfly.org Mon Jan 9 17:14:05 2006 From: nomi at fruitfly.org (Nomi Harris) Date: Mon, 9 Jan 2006 14:14:05 -0800 Subject: [DAS2] DAS vs. Java Web Services In-Reply-To: References: Message-ID: <17346.57389.556939.673301@spongecake.lbl.gov> i was talking to someone in the apollo community about writing a DAS/2 adapter for apollo, and he said: > I think the Java Web Services model has been proven more so than the DAS > model for standardized web application communication. this is an interesting claim, and i was wondering if you have any comment on why this is wrong (i assume you all disagree with it, or else you wouldn't be working on DAS/2). i think we should address this issue in the grant--maybe we can add it to the progress report? otherwise, the review committee could come back and say, "why don't you just use Java Web Services instead of developing this new standard?" Nomi From Steve_Chervitz at affymetrix.com Mon Jan 9 19:32:20 2006 From: Steve_Chervitz at affymetrix.com (Steve Chervitz) Date: Mon, 09 Jan 2006 16:32:20 -0800 Subject: [DAS2] DAS/2 weekly meeting notes for 9 Jan 2006 In-Reply-To: <17346.49712.576001.115347@spongecake.lbl.gov> Message-ID: Nomi, > From: Nomi Harris > Date: Mon, 9 Jan 2006 12:06:08 -0800 > > On 9 January 2006, Chervitz, Steve wrote: >> Notes from the weekly DAS/2 teleconference, 9 Jan 2006. > > thanks for sending these detailed notes, steve. You're welcome. > i'm a little confused, reading the notes, about what the final decision > was about the code sprint. there's going to be one in the UK, feb 6-11, > and then one in california, some time in march? when? once we have > dates, i'd be happy to help with planning (e.g. housing and meeting > rooms) if needed. The dates for the March sprint are not established yet, but it's looking like the week of 13th or the 20th. >> [A] Andreas will post announcement for Feb code sprint, set up registration >> form, reserve room >> >> SL: I will notify Nomi about it today. When is the progress report for >> the grant review due? > > what do i need to do in terms of participating in this? obviously, i > won't be going to england for it. will we be scheduling extra > teleconferences, or F2F meetings with bay-area people, or what? Gregg mentioned getting Bay area folks together along with Allen Day if he can make it. Nothing concrete has been planned though. Try to keep your calendar clear for that week as much as possible (feb 6-11). >> GH: Not sure. Sent one in may/june last year. >> >> SL: Important to send report before review committee sits. Would be >> good to report on the code sprint for the review. > >> GH: What do we want to accomplish when we have one week to do it? >> >> SL: DAS/2 adaptor for apollo. > > i am already starting work on this--should i stop? initially, i've been > trying to construct arguments to the the DAS/2 server at > http://das.biopackages.net/das/genome to get some sample features (using > http://www.biodas.org/documents/das2/das2_get.html#features as my > reference). Andrew is planning to commit changes to the retrieval spec a week or so before the code sprint, so it may make sense to hold off on your DAS-related work right now and focus on other projects so that you will have a clear schedule during the sprint. >> GH: >> - Make IGB code for DAS/2 client, update to reflect changes in spec >> implement unimplemented stuff. > > IGB already has a DAS/2 client, right? the comma is confusing me--are > you just saying the IGB DAS/2 client code needs to be updated and > extended? After Andrew commits spec change later this month, updates will be necessary. Also, it's not currently a complete implementation. >> - DAS/2 server at Affy - bring it up to the spec as well. not a full >> impl but was compliant 3 mos ago. > is that http://das.biopackages.net/das/genome? No, http://netaffxdas.affymetrix.com >> GH: March sprint, anytime in the middle 3 weeks of march. >> >> AD: will be at a san diego workshop in march. Back in the states >> in Mid feb. >> >> SC: There is a MAGE v2 workshop/jamboree in Benecia, CA on 7-11 >> March. Should probably aim for later March. Also will be involved in a >> netaffx quarterly update. > > the CBIO project meeting is march 2-4. i will be away march 23-26 (trip > planned long ago). are a lot of people going to participate in this MAGE > workshop? maybe it would work well to have the code sprint right after > it, say, march 13-19? i don't think we want to make it any later than > that or there won't be time to write it up for the progress report. in > fact, that might already be too late. The MAGE workshop won't be very large, since it's specifically just for development of the next version of it. It's possible there could be some people/organizations coming out for that who have DAS interests as well and might consider attending the sprint. I'll inquire. Steve > Nomi > From td2 at sanger.ac.uk Tue Jan 10 04:03:26 2006 From: td2 at sanger.ac.uk (Thomas Down) Date: Tue, 10 Jan 2006 09:03:26 +0000 Subject: [DAS2] DAS vs. Java Web Services In-Reply-To: <17346.57389.556939.673301@spongecake.lbl.gov> References: <17346.57389.556939.673301@spongecake.lbl.gov> Message-ID: On 9 Jan 2006, at 22:14, Nomi Harris wrote: > i was talking to someone in the apollo community about writing a DAS/2 > adapter for apollo, and he said: > >> I think the Java Web Services model has been proven more so than >> the DAS >> model for standardized web application communication. > > this is an interesting claim, and i was wondering if you have any > comment > on why this is wrong (i assume you all disagree with it, or else you > wouldn't be working on DAS/2). i think we should address this > issue in > the grant--maybe we can add it to the progress report? otherwise, the > review committee could come back and say, "why don't you just use Java > Web Services instead of developing this new standard?" It would be interesting to know a little more about what's mean by "Java Web Services". I'm guessing that you contact is talking about "web services based on SOAP, WSDL and associated technologies". There's nothing Java-centric here, although I guess it's true that a lot of the advocates for these technologies are coming from a Java or .NET background. DAS (and DAS/2 in particular) aims for a RESTful style of interaction: http://www.ics.uci.edu/~fielding/pubs/dissertation/ top.htm I think the main argument for this was that REST services, which put all the query information in a URL, are easier for "casual" programmers (who aren't familiar with SOAP client libraries and the like) to script about -- and it's even possible to fire a query off by typing a URL in your web browser. The downsides of REST are that you get less benefit from existing client libraries and server frameworks, and that (at least in my opinion) it's harder to clearly express a rich query language as URLs than as POSTed XML fragments. Thomas. From ap3 at sanger.ac.uk Tue Jan 10 04:42:03 2006 From: ap3 at sanger.ac.uk (Andreas Prlic) Date: Tue, 10 Jan 2006 09:42:03 +0000 Subject: [DAS2] DAS2 code sprint February 6th-11th Message-ID: This is an invitation for the first DAS2 code sprint, which will take place from February 6th - 11th in Hinxton, Cambridge, U.K. If you want to join please reply to ap3 at sanger.ac.uk and give the following details: a) name and affiliation b) topic you would like to work on c) special requirements like "need help to find accommodation" This is to estimate the number of participants and in order to reserve enough room. ----------------------------------------------------------------------- Andreas Prlic Wellcome Trust Sanger Institute Hinxton, Cambridge CB10 1SA, UK +44 (0) 1223 49 6891 From nomi at fruitfly.org Tue Jan 10 14:32:07 2006 From: nomi at fruitfly.org (Nomi Harris) Date: Tue, 10 Jan 2006 11:32:07 -0800 Subject: [DAS2] DAS vs. Java Web Services In-Reply-To: References: <17346.57389.556939.673301@spongecake.lbl.gov> Message-ID: <17348.2999.922746.913338@spongecake.lbl.gov> On 10 January 2006, Thomas Down wrote: > On 9 Jan 2006, at 22:14, Nomi Harris wrote: > > > i was talking to someone in the apollo community about writing a DAS/2 > > adapter for apollo, and he said: > > > >> I think the Java Web Services model has been proven more so than > >> the DAS > >> model for standardized web application communication. > > > > this is an interesting claim, and i was wondering if you have any > > comment > > on why this is wrong (i assume you all disagree with it, or else you > > wouldn't be working on DAS/2). i think we should address this > > issue in > > the grant--maybe we can add it to the progress report? otherwise, the > > review committee could come back and say, "why don't you just use Java > > Web Services instead of developing this new standard?" > > It would be interesting to know a little more about what's mean by > "Java Web Services". I'm guessing that you contact is talking about > "web services based on SOAP, WSDL and associated technologies". > There's nothing Java-centric here, although I guess it's true that a > lot of the advocates for these technologies are coming from a Java > or .NET background. > > DAS (and DAS/2 in particular) aims for a RESTful style of interaction: > > http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm > > I think the main argument for this was that REST services, which put > all the query information in a URL, are easier for "casual" > programmers (who aren't familiar with SOAP client libraries and the > like) to script about -- and it's even possible to fire a query off > by typing a URL in your web browser. > > The downsides of REST are that you get less benefit from existing > client libraries and server frameworks, and that (at least in my > opinion) it's harder to clearly express a rich query language as URLs > than as POSTed XML fragments. > > Thomas. i certainly agree that "java web services" is vague and it's not clear exactly what he meant by that. what i got from his statement was a knee-jerk reaction against DAS, and i think that's something we need to take seriously, because the people who review our grant could also think, with or without justification, "why are they working on DAS when web services is a better way to go?" i see at least three aspects of the DAS vs. web services debate: 1. which technology is easier for programmers to use? 2. which delivers the data faster (and/or more flexibly)? 3. what is the public perception of the two technologies and the availability of servers? even if DAS is easier to program AND faster, if most labs are choosing to make their data available via web services (or some other DAS alternative), we're going to be fighting an uphill battle. i think it is worthwhile for us to ponder these issues for our own clarity of purpose, but also so that we can convincingly argue to the grant reviewers that they should be supporting DAS/2. Nomi From ed_erwin at affymetrix.com Tue Jan 10 18:56:22 2006 From: ed_erwin at affymetrix.com (Ed Erwin) Date: Tue, 10 Jan 2006 15:56:22 -0800 Subject: [DAS2] DAS vs. Java Web Services In-Reply-To: <17348.2999.922746.913338@spongecake.lbl.gov> References: <17346.57389.556939.673301@spongecake.lbl.gov> <17348.2999.922746.913338@spongecake.lbl.gov> Message-ID: <43C449A6.90601@affymetrix.com> Nomi Harris wrote: > On 10 January 2006, Thomas Down wrote: > > ... the people who review our grant could also think, > with or without justification, "why are they working on DAS when web > services is a better way to go?" ... The original DAS/2 grant proposal did include a discussion of why the REST approach was chosen instead of the SOAP-based web-services model. From nomi at fruitfly.org Tue Jan 10 20:03:57 2006 From: nomi at fruitfly.org (Nomi Harris) Date: Tue, 10 Jan 2006 17:03:57 -0800 Subject: [DAS2] DAS vs. Java Web Services In-Reply-To: <43C449A6.90601@affymetrix.com> References: <17346.57389.556939.673301@spongecake.lbl.gov> <17348.2999.922746.913338@spongecake.lbl.gov> <43C449A6.90601@affymetrix.com> Message-ID: <17348.22909.865740.607273@spongecake.lbl.gov> On 10 January 2006, Ed Erwin wrote: > Nomi Harris wrote: > > On 10 January 2006, Thomas Down wrote: > > > > ... the people who review our grant could also think, > > with or without justification, "why are they working on DAS when web > > services is a better way to go?" ... > > The original DAS/2 grant proposal did include a discussion of why the > REST approach was chosen instead of the SOAP-based web-services model. oh, good. i'll have to go back and read that more carefully. Nomi From dalke at dalkescientific.com Sun Jan 15 18:33:13 2006 From: dalke at dalkescientific.com (Andrew Dalke) Date: Mon, 16 Jan 2006 01:33:13 +0200 Subject: [DAS2] "namespace" name Message-ID: I propose using "collection" instead of "namespace" "namespace" is ambiguous because it means so many things. Here's what it would look like Note also that I have a new 'type' field to describe what's in the collection. Previously there was no way for a client to figure out which namespace was which. Andrew dalke at dalkescientific.com From dalke at dalkescientific.com Sun Jan 15 18:31:02 2006 From: dalke at dalkescientific.com (Andrew Dalke) Date: Mon, 16 Jan 2006 01:31:02 +0200 Subject: [DAS2] single source document format Message-ID: I've been working on updating the spec. So far working on the sources document(s). We have 2 or 3 document formats, depending on how you count. - the top-level URL for a server returns a 'sources' request, which can return 0 or more sources (each with 0 or more versions) - the top-level URL for a given organism/database returns a 'source' request which returns 1 source (each with 0 or more version) - a 'versioned source' request, which returns more details about the given version of the source (one version) Currently the first 2 return the same document type, which is similar to but different from the 3rd. ** I propose that all three return a document of the same content type, instead of returning 2 different document types. ** "How are they currently different?" you ask. The versioned source request returns a bit more information than the normal source request. It returns the 'NAMESPACE' fields, which point out that 'features' are available at XYZ and 'types' available at ABC. It also (now) has a key/value table for metadata properties that Andreas (Prlic) wanted. NOTE: there would still be three URLs involved. The only difference in this proposal is that all of them return a document of the content-type 'application/x-das-sources+xml' and there is no need to drill down to the 3rd level URL if given the results from the 1st level URL. Advantages: - a single request to a data server (including to the metadata server) to get the main information about a given data source and version. That is, no need to go to the versioned source to ask it for the place to get information about the 'types' or 'properties' URL. - Andreas pointed out that he needs a bit more information in the SOURCES for the registry server. This is also information that should be available from the database/version itself. I would prefer that they have the same format and structure, for better code reuse. (BTW, another name for 'registry server' might be 'DAS aggregator'.) Disadvantages: - the registry server must return more data (but there isn't that much) - there's a better chance of registry server data invalidation (though those fields don't change much) As an alternative, they could have the same format but the registry server returns only a subset of the data, so a client can query the registry server to find the versioned source URL then query that URL to get the complete data set. Andrew dalke at dalkescientific.com From dalke at dalkescientific.com Sun Jan 15 18:31:10 2006 From: dalke at dalkescientific.com (Andrew Dalke) Date: Mon, 16 Jan 2006 01:31:10 +0200 Subject: [DAS2] properties Message-ID: <5d78d8ff5605327d8a23bde5b4177f1d@dalkescientific.com> Working more on the property tables. Here's my understanding and what I want to do. Features are of type T and have properties P1, P2, P3, ... The given 'T' is a URL. Fetching that gives property information about the given type Tp1, Tp2, Tp3, ... The way things are done now, features and types both have a element, though they are different. Features have elements like 23 0 Types have elements like These will be merged into a single common pattern, which looks like (See [1] below) The key names are string of the form [a-zA-Z_][a-zA-Z0-9_]* (See [2] below) In doing this I noticed that feature properties have a URL but feature type properties do not. I think this came about because of the belief that XML namespace definitions (like 'bg:' in the above example) would expand inside of element attribute values. The keys names for these two properties overlap. That is, a feature property should override the associated feature type property. (For example, "most tRNAscan results are in red but this particular feature is shown in blue".) (But see [3] below; stylesheet/view information might better be stored different from model data.) There are two options: 1. make both refer to URLs For example, http://www.biodas.org/das2-spec/bgcolor/ 2. make both refer to arbitrary/non-resolvable/opaque identifiers For example, define that the string "bgcolor" means "background color" The advantage to the first is automatic determination of information about the property, as Again though I express my belief that dynamic property lookups like this are mostly good in theory. In practice they aren't that useful to end-user apps. ** I propose that properties are opaque strings with no mapping to URLs and no way to resolve them to dynamically discover information about the property. Instead, standardized properties are described by a yet-to-be-written document. ** If in the future we decide we need it we can add it in one of several ways: Verbose: More likely; have "/properties" return a document either describing the property information directly or mapping the property name into a resolvable URL which contains the property information. ** Are there any client implementers here who will do anything with dynamic lookup of the property information? ** [1]: if we need values which are hyperlinks then it should be and if we want the ability to embed HTML or XML then we can support something like Here is <b>XML!</b> Hi! As there are no current use cases for this I will not put them into the spec. I mention them because I think they will be useful. [2]: We will need a document listing standard properties, like 'bgcolor'. People working on new properties should use a unique prefix like 'ABC_' (as in 'ABC_bgcolor'). Basically I'm assuming there won't be much of a namespace problem. [3]: But there's still the issue of stylesheets. Should this data be directly associated with the data or made available as an external stylesheet? HTML stylesheets let you annotate by class ("feature type") and id (we could use the feature URL), along with precedence based on stylesheet source. Andrew dalke at dalkescientific.com From dalke at dalkescientific.com Mon Jan 16 10:35:22 2006 From: dalke at dalkescientific.com (Andrew Dalke) Date: Mon, 16 Jan 2006 17:35:22 +0200 Subject: [DAS2] today's meeting is implementation, right? Message-ID: <24c30a26e92d369408b1b6a2c8ec0756@dalkescientific.com> Today's phone conference is on implementation, right? I ask because the network here has been going up and down and the voip connection quality might be poor tonight for me. Andrew dalke at dalkescientific.com From aloraine at gmail.com Mon Jan 16 11:34:09 2006 From: aloraine at gmail.com (Ann Loraine) Date: Mon, 16 Jan 2006 08:34:09 -0800 Subject: [DAS2] today's meeting is implementation, right? In-Reply-To: <24c30a26e92d369408b1b6a2c8ec0756@dalkescientific.com> References: <24c30a26e92d369408b1b6a2c8ec0756@dalkescientific.com> Message-ID: <83722dde0601160834kd3b52ev14f34bb30cd2288d@mail.gmail.com> Probably today the meeting is off since it's a holiday? (MLK's birthday.) -Ann On 1/16/06, Andrew Dalke wrote: > Today's phone conference is on implementation, right? > > I ask because the network here has been going up and down and > the voip connection quality might be poor tonight for me. > > Andrew > dalke at dalkescientific.com > > _______________________________________________ > DAS2 mailing list > DAS2 at portal.open-bio.org > http://portal.open-bio.org/mailman/listinfo/das2 > -- Ann Loraine Assistant Professor Section on Statistical Genetics University of Alabama at Birmingham http://www.ssg.uab.edu http://www.transvar.org From td2 at sanger.ac.uk Mon Jan 23 05:17:37 2006 From: td2 at sanger.ac.uk (Thomas Down) Date: Mon, 23 Jan 2006 10:17:37 +0000 Subject: [DAS2] properties In-Reply-To: <5d78d8ff5605327d8a23bde5b4177f1d@dalkescientific.com> References: <5d78d8ff5605327d8a23bde5b4177f1d@dalkescientific.com> Message-ID: On 15 Jan 2006, at 23:31, Andrew Dalke wrote: > > Types have elements like > > > > > > These will be merged into a single common pattern, which > looks like > > > > (See [1] below) > > The key names are string of the form [a-zA-Z_][a-zA-Z0-9_]* > > (See [2] below) This seems to be inventing a new namespace-management mechanism. I'm always a bit nervous about schemes which require someone to maintain a registry of namespaces. Was there really a problem with the old system of using the XML document's namespace map to scope property names? The one thing I saw missing from the old spec was a mechanism for doing namespace-scoped property queries. I guess shoehorning this into an application/x-www-form-urlencoded query isn't ideal, but it could be done. How about feature?xmlns:bg=http:%2f%2fwww.bioperl.org% 2fbiographics%2fproperties;att=bg:fgcolor:red Thomas. From dalke at dalkescientific.com Mon Jan 23 08:34:03 2006 From: dalke at dalkescientific.com (Andrew Dalke) Date: Mon, 23 Jan 2006 15:34:03 +0200 Subject: [DAS2] properties In-Reply-To: References: <5d78d8ff5605327d8a23bde5b4177f1d@dalkescientific.com> Message-ID: <08c9b852196e449cba6b16f99c3c3212@dalkescientific.com> Thomas wrote: > This seems to be inventing a new namespace-management mechanism. I'm > always a bit nervous about schemes which require someone to maintain a > registry of namespaces. Was there really a problem with the old > system of using the XML document's namespace map to scope property > names? I don't have a good feeling about any solution to this. It comes down to what people will be using these property tables for. Are they only meant for machines? For people? For both? Is it okay to restrict the key names? For example, will there be keys like "5'UTR"? If so, we'll need to work around the XML syntax restrictions on an element name. Oh, and can non-ASCII/non-Latin1 unicode characters be included in key names? Will people be able to add their own properties? Eg, an editable table interface to add "curator" "Andrew Dalke", assuming no curator element is already defined. Searching is one problem. The syntax for doing the search is only part of the problem. Different fields may need different search types. Eg, "starts with" vs. "contains" vs. "range" searches. Most of the properties are stylesheet related. This made me think about HTML stylesheets, where old HTML had elements like "font" and "color" but modern ones put the style data elsewhere. The style data is very well defined, and not done through URLs. What if we did the same? Then fields like 'bgcolor', 'glyph', etc. would indeed be in a completely different namespace. Of course then HTML has the "style" attribute to override that, but through an embedded stylesheet. I honestly don't know. This is something I hope can be worked on during the sprint in a couple weeks. > The one thing I saw missing from the old spec was a mechanism for > doing namespace-scoped property queries. I guess shoehorning this > into an application/x-www-form-urlencoded query isn't ideal, but it > could be done. > How about > > > feature?xmlns: > bg=http:%2f%2fwww.bioperl.org%2fbiographics%2fproperties; > att=bg:fgcolor:red Yeah, I'm shaky on that as well. The solutions I came up with with are: - your approach - Clark names, like att={http:%2f%2fwww.bioperl.org%2fbiographics%2fproperties}fgcolor - "aliases" Let me explain the last as I'm going to propose it for the sequence data. In sequence data there are URLs http://example.org/foo/bar/residues/Chr1 http://example.org/foo/bar/residues/Chr2 ... These are fixed and finite. I propose that a request of http://example.org/foo/bar/residues returns a document like this To query for features on a given sequence use its 'name' in the query, overlaps=Chr3/1000:2000 This works for sequences because there's no chance of conflicting names. All annotation servers refer to the same sequence data set. I'm less sure about it's feasibility for generic properties. If we do that we might as well just use the short names and not have full URLs. Here's my view. 1) We have a large number of stylesheet properties. We must support these. They keys come from a restricted vocabulary, which must be machine readable and well-defined. They do not need to be searchable (who will search for all "red" elements, especially if the client can apply its own stylesheet definitions?) These can be DAS elements, red or given the general aversion to cdata from many of the DAS people More specifically, elements which serve only to override some other as of yet undefined stylesheet document. 2) Some properties have (approximately) arbitrary contents for the key and value. Searches will be done as .. some server-specific method? (Probably substring, exact or word match. Should we require a specific type of search?) These will tend to be software or group specific. Eg, "last edited by" "Andrew". I think these are best done as a key/value table, with no restrictions on the key or value. 3) Some properties are in the middle. For example, scores. They need to be well defined. But score searches should be range searches (scores better than 10E-4, more than 80% identifies). I don't know how to handle these. 4) opaque extensions. These are outside the realm of key/value data, and used mostly as extension elements. These can be done through allowing non-DAS elements in part of the returned document. Eg, Andrew dalke at dalkescientific.com From td2 at sanger.ac.uk Mon Jan 23 10:49:52 2006 From: td2 at sanger.ac.uk (Thomas Down) Date: Mon, 23 Jan 2006 15:49:52 +0000 Subject: [DAS2] properties In-Reply-To: <08c9b852196e449cba6b16f99c3c3212@dalkescientific.com> References: <5d78d8ff5605327d8a23bde5b4177f1d@dalkescientific.com> <08c9b852196e449cba6b16f99c3c3212@dalkescientific.com> Message-ID: <8C0328BC-6AFE-4C35-B2EF-DF85FFA71E2D@sanger.ac.uk> On 23 Jan 2006, at 13:34, Andrew Dalke wrote: > Thomas wrote: > >> This seems to be inventing a new namespace-management mechanism. >> I'm always a bit nervous about schemes which require someone to >> maintain a registry of namespaces. Was there really a problem >> with the old system of using the XML document's namespace map to >> scope property names? > > I don't have a good feeling about any solution to this. It comes > down to what people will be using these property tables for. > > Are they only meant for machines? For people? For both? I've been seeing this very much as something for machines. You don't want to be showing end-users your stylesheet data, at least not in XML format -- although smarter clients might want to have a dedicated stylesheet editor, of course. The current examples in das2_get.html imply that there is a special type of property for "notes" (i.e. chunks of text you want to show the user): This is a telomeric repeat I'd taken this to imply that other types of property were generally *not* meant to be shown directly to the user, except in "special" ways by clients that understand their semantics. But I guess there are cases where you want to show "tag-value" type data to the end user (I'm thinking here about adding extra rows to tables like the ones you see on http://www.ensembl.org/Drosophila_melanogaster/ geneview?gene=CG11015). I think there's an argument for handling this a bit differently, for example: This is a telomeric repeat (This kind of solution appears to drop in pretty nicely if we allow arbitrary XML "extension elements"). Thomas. From dalke at dalkescientific.com Mon Jan 23 11:11:34 2006 From: dalke at dalkescientific.com (Andrew Dalke) Date: Mon, 23 Jan 2006 18:11:34 +0200 Subject: [DAS2] properties In-Reply-To: <8C0328BC-6AFE-4C35-B2EF-DF85FFA71E2D@sanger.ac.uk> References: <5d78d8ff5605327d8a23bde5b4177f1d@dalkescientific.com> <08c9b852196e449cba6b16f99c3c3212@dalkescientific.com> <8C0328BC-6AFE-4C35-B2EF-DF85FFA71E2D@sanger.ac.uk> Message-ID: <8ddfbc3373d9d3cbcdb66e24d52d2ba7@dalkescientific.com> Thomas: > I've been seeing this very much as something for machines. You don't > want to be showing end-users your stylesheet data, at least not in XML > format -- You wouldn't. It's a list of keys and values, with strings for both. That's a property table, and there are many ways to view it. I'm fine with having them be elements instead of this thing. That means we'll define: - the element name - the search parameter(s) for searching that element (if one exists) - what it means to search that field I don't think the current scheme of att=score:0.3 for searching attributes will work well. It's too field dependent. Instead we would say: The element name is "das:score" The search term is "score" with operators "<", ">", "=", "<=" and ">=" eg score>=0.3 (quoting as needed.) I'm not sure that the stylesheet information should be in the types field, except as a way to override some other default. For example, should I be able to specify in a style sheet that all "chromosome_variation" are colored blue, which includes "chromosomal_duplication" and "uninverted_intrachromosomal_transposition"? Or should the server return back ... > although smarter clients might want to have a dedicated stylesheet > editor, of course. Agreed. Having the styles well-defined enables sophisticated editors. Eg, ones that know "bgcolor" can take a color selector pane. Andrew dalke at dalkescientific.com From nomi at fruitfly.org Wed Jan 25 22:49:54 2006 From: nomi at fruitfly.org (Nomi Harris) Date: Wed, 25 Jan 2006 19:49:54 -0800 (PST) Subject: [DAS2] DAS/2 GET requests In-Reply-To: <8ddfbc3373d9d3cbcdb66e24d52d2ba7@dalkescientific.com> References: <5d78d8ff5605327d8a23bde5b4177f1d@dalkescientific.com> <08c9b852196e449cba6b16f99c3c3212@dalkescientific.com> <8C0328BC-6AFE-4C35-B2EF-DF85FFA71E2D@sanger.ac.uk> <8ddfbc3373d9d3cbcdb66e24d52d2ba7@dalkescientific.com> Message-ID: <17368.18146.195226.166165@kinked.lbl.gov> i have gotten my apollo das/2 adapter to read das2xml, and now i want to write the GET part. is the GET protocol now stable, and is there a reference server implementing it? i've been using the affy server because i couldn't get data from the biodas server (only metadata). if GET is not yet stable, can i have an estimate of when it will be? thanks, Nomi From nomi at fruitfly.org Thu Jan 26 18:56:18 2006 From: nomi at fruitfly.org (Nomi Harris) Date: Thu, 26 Jan 2006 15:56:18 -0800 (PST) Subject: [DAS2] Apollo and DAS/2 priorities In-Reply-To: <17368.18146.195226.166165@kinked.lbl.gov> References: <5d78d8ff5605327d8a23bde5b4177f1d@dalkescientific.com> <08c9b852196e449cba6b16f99c3c3212@dalkescientific.com> <8C0328BC-6AFE-4C35-B2EF-DF85FFA71E2D@sanger.ac.uk> <8ddfbc3373d9d3cbcdb66e24d52d2ba7@dalkescientific.com> <17368.18146.195226.166165@kinked.lbl.gov> Message-ID: <17369.24994.880706.685148@kinked.lbl.gov> i am at affy today, and was discussing with gregg what i should focus on before the code sprint (feb 6). given the short time frame before we need to submit the progress report (gregg is trying to find out when that is due), it's important to spend that time on things that will show visible progress towards apollo/das2 connectivity. the part i've completed--loading features from das2xml and displaying them in apollo--is definitely good in terms of bang for the buck, because you can look at an IGB display and an apollo display of the same data and it's clear that they match. it's obviously important to get the GET requests working before we submit the progress report; gregg and i hoping the updates to the GET spec will be done very soon so that he can bring the server up to spec before the code sprint, since we clearly need a current working server available during the code sprint to use for testing. in the meantime, there are several options for what i can work on: - gregg thinks the specs for source and type GETs are more stable than the feature GETs, so i could start trying to get source & type. - andrew, if you could give me an updated das2xml example of features, i can make sure that my das2xml reader is up to spec (right now i'm using das2xml from gregg's server, which is at least three months out of date). - gregg and i are not sure whether it makes sense for me to start working on a das2xml writer. it would be nice to be able to validate round-tripping, and it's also a step towards server writeback (which we probably won't be able to work on anytime soon). however, i would need an updated feature xml example in order to work on this. - i haven't yet tried loading sequence. there are several levels on which that could be implemented: - read sequence from a das2xml file - get sequence from das/2 server - fetch sequence automatically as needed (lazy loading) i may start working on reading sequence from a das2xml file first, since that's a necessary step in order to read it from a server anyway. suzi, any feedback on priorities? Nomi From td2 at sanger.ac.uk Fri Jan 27 04:14:00 2006 From: td2 at sanger.ac.uk (Thomas Down) Date: Fri, 27 Jan 2006 09:14:00 +0000 Subject: [DAS2] Apollo and DAS/2 priorities In-Reply-To: <17369.24994.880706.685148@kinked.lbl.gov> References: <5d78d8ff5605327d8a23bde5b4177f1d@dalkescientific.com> <08c9b852196e449cba6b16f99c3c3212@dalkescientific.com> <8C0328BC-6AFE-4C35-B2EF-DF85FFA71E2D@sanger.ac.uk> <8ddfbc3373d9d3cbcdb66e24d52d2ba7@dalkescientific.com> <17368.18146.195226.166165@kinked.lbl.gov> <17369.24994.880706.685148@kinked.lbl.gov> Message-ID: <99DBB4D4-098D-44F0-98A1-ACCFA15D74A0@sanger.ac.uk> On 26 Jan 2006, at 23:56, Nomi Harris wrote: > - i haven't yet tried loading sequence. there are several levels > on which > that could be implemented: > - read sequence from a das2xml file > - get sequence from das/2 server > - fetch sequence automatically as needed (lazy loading) > i may start working on reading sequence from a das2xml file first, > since > that's a necessary step in order to read it from a server anyway. Currently I don't think there's a "das2xml" format for sequence, the only format currently recommended in the spec is FASTA. This got argued about a few weeks back but I think the decision was to stick with FASTA. Not sure what you're meant to do with the header line, I think the contents are undefined and clients should ignore it. Thomas. From dalke at dalkescientific.com Fri Jan 27 10:18:15 2006 From: dalke at dalkescientific.com (Andrew Dalke) Date: Fri, 27 Jan 2006 17:18:15 +0200 Subject: [DAS2] stylesheet question Message-ID: I'm adding the DAS1 stylesheet information to the spec. I don't want to change the data model that much. I have a few questions about the existing DAS1 stylesheet. In the text glyph definition there is a element which I assume is the string to use for the label. There is also a