Re: [Mged-mage] MAGE-TAB officail parser

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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