From: Miller, M. D (Rosetta) <Michael_Miller@Rosettabio.com> - 2007-03-23 17:51:49
|
hi don, =20 as this is the real world, one cannot dictate that developers cannot go off on their own to do what ever they want. so my thought is that realistically we can not require something that is unlikely to be satisfied. =20 what we can do is release THE official validating parser which if there is a question as to whether a set of files that claims to be MAGE_TAB compliant is or isn't, it will definitively answer yea or nay. =20 if someone were to find this official parser wasn't efficient enough in the context of their application they would not be doing their job to develop one that did work fast enough for their application. but having this official validating parser would be wonderful to make sure the in-house application stayed compliant. =20 for instance, in-house, we have our own version of the java MAGEstk parser which is much more efficient and faster than the one in the official stk. (actually i'd like to put it in the official stk code but it got caught up in some unnecessary imports that prevent releasing it until those can be removed.) =20 cheers, michael =20 ________________________________ From: Don Maier [mailto:dM...@ge...]=20 Sent: Friday, March 23, 2007 10:31 AM To: Miller, Michael D (Rosetta) Cc: Junmin Liu; mged-mage2; MGED-mage Subject: Re: [Mged-mage] [Mged-mage2] MGED Jamboree next week - March 27-30! =09 =09 Hi Michael,=20 Thank you for your enthusiastic support for the "one-parser" requirement -- at least, in your initial statement about it. Two comments about your comments: i) There likely will be a performance tradeoff. In my view, any modest performance cost is utterly trivial compared to the gain in solving this problem once and for everyone. Of course, there were those who invoked the specter of performance to justify continuing continuing careers in assembly language programming. ii) The architecture of a push parser makes it possible to perform any set of "custom" actions that are conjoined with the parse. This includes performing operations on your favorite database and flagging constructs that an installation prefers not to support. There *is* a problem, a really big problem, with having more than one parser. Two is too many. I hope that I can clearly convey this to the group. Regards, Don M. On Mar 23, 2007, at 9:55 AM, Miller, Michael D (Rosetta) wrote: hi junmin, that's great work, if i could get a copy of the presentation when it's ready, that would be much appreciated. hi don, a) There is thought to be a strong requirement to have=20 exactly one=20 MAGE-TAB parser in one body of code in one language that=20 can be used from=20 either a Java or a Perl programming environment. =20 Satisfying this requirement=20 would ensure that MAGE-TAB never destroys itself on the=20 shoals of disagreeing=20 acceptors. i think this is a great requirement, similar to the OMG compliancy section, but i have one caveat with the wording. yes, we definitely should have as a goal a definitive MAGE-TAB parser that has a mode that verifies that a set of files is MAGE-TAB compliant (including resolving the references between the files). And it should have a mode that developers could certainly use as the basis of their import implementation. exactly one=20 MAGE-TAB parser in one body of code in one language that=20 can be used from=20 either a Java or a Perl programming environment. =20 my caveat is that there is no problem having more than one, often for efficiency reasons for an application there would be a parser tuned to specific database schema and additional application rules for standard, compliant MAGE-TAB files (for instance, the application rules might restrict MAGE-TAB to require certain columns for the application that in general aren't required). i would change the wording to: exactly one official validating MAGE-TAB parser in one body of code in one language that=20 can also be used from=20 either a Java or a Perl programming environment by any import application. note that if it is in one language there will be by necessity, i think, a bit of an impedance using it in a different language. cheers, michael -----Original Message----- From: mge...@li...=20 =09 [mailto:mge...@li...] On Behalf=20 Of Junmin Liu Sent: Friday, March 23, 2007 9:17 AM To: Don Maier Cc: mged-mage2; MGED-mage Subject: Re: [Mged-mage2] MGED Jamboree next week - March 27-30! Hi, Don and Jamboree attendees, Since last Oct., for one of the requirement of our in-house=20 data loading=20 pipeline, we developed an extendable framework MR_Ti and a set of=20 toolkits to help loading MIAMI-compliant documents in=20 different formats=20 into our GUS schema. Chris has suggested me to present this on the=20 Jamboree to get feedback and to see if it can be useful to the=20 communities. Note MAGE-Tab is part of our pipeline, we have started to=20 generate and=20 load MAGE-Tabs to GUS, we will also like to show public the files we=20 have and make sure they are exchangable and compliant with=20 MAGE-Tab spec.=20 1.0 release. Thanks, ---junmin On Wed, 21 Mar 2007, Don Maier wrote: Hi friends, We're looking forward to seeing and meeting with you in=20 next week in sunny=20 California. Current forecasts are for a cloudy Tuesday,=20 but a sunny=20 remainder of the week in the upper 60's. Here's my current list of attendees and agenda. Please=20 let me know if you=20 wish to contribute any more bodies or agenda items! Regards, Don Maier MAGE Jamboree: March 27 - 30 Stanford University: Clark Center, Rm. 362 Attendees: 1) Cathy Ball (SMD) 2) Cate Beauheim (Stanford) 3) Alvis Brazma (EBI) 4) Steve Chervitz (Affymetrix) 5) Junmin Liu (U. Penn) 6) Don Maier (SMD) 7) Tim Rayner (EBI) 8) Ugis Sarkans (EBI) 9) Paul Spellman (Lawrence Berkeley National Laboratory) 10) Joe White (Dana-Farber/Harvard Cancer Center) Agenda: 1) Tim - Final version of MAGE-TAB 2) Alvis/Ugis - MAGE-TAB object model: a) Possible move to FUGE-TAB b) Discussion of basic concepts (no formal proposal yet). 3) Don - The "one-parser" requirement and how to satisfy=20 it for MAGE-TAB: a) There is thought to be a strong requirement to have=20 exactly one=20 MAGE-TAB parser in one body of code in one language that=20 can be used from=20 either a Java or a Perl programming environment. =20 Satisfying this requirement=20 would ensure that MAGE-TAB never destroys itself on the=20 shoals of disagreeing=20 acceptors. b) Proposal for how to satisfy this requirement. =09 ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash =09 http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ Mged-mage mailing list Mge...@li... https://lists.sourceforge.net/lists/listinfo/mged-mage =09 =09 |