Re: [Gusdev-gusdev] Re: plugin for XML

[Terry C. <tw...@cs...>]

I wrote:
> Without a general strategy, we would need to craft yet another plugin. 
> On the other hand, the XML-to-GUS mapping approach would handle this readily, 
> making for a swift, general-purpose implementation of the retroelement plugin.

What I wrote here sounds silly, typo that it is. 
I mean, writing a plugin from "first principles" in contrast to
a simplified writing using a flexible mapping.  Put differently, 
this has potential to reduce the overall code quantity.

Terry


On  0, Terry Clark <tw...@cs...> wrote:
> >  - would this be able to work for the more common, non-trivial case 
> > where the object models differ more significantly?  Angel has done a lot 
> > of thinking about this for his object mapper which maps MAGE-ML into GUS.
> 
> I'm looking forward to hearing Angel's comments. The mapper I'm proposing
> targets XML schema to relational schema (and GUS Objects). 
> I have used the notation only for simple schemas, but
> Bourret describes the method as a complete mapping from W3C XML schemas 
> to relationl schemas.
>     http://www.xml.com/pub/a/2001/05/09/dtdtodbs.html
>     http://www.rpbourret.com/xml/SchemaMap.htm
> The simplicity of the notation is a plus for error and overhead
> reduction in writing mappings. 
> 
> 
> >  - will you go directly to SQL or will you go to gus objects?  In a 
> > simple case like this, it might make sense to go to SQL for efficiency 
> > reasons, if you are expecting huge inputs.
> 
> It seems preferable to go to GUS objects through the object layer to enforce 
> adherence to GUS policies.  Basically, I see this mapper plugin approach as 
> a front end to the object layer driven by XML-to-DB maps (supplied in XML files) 
> that are intrepretted by the plugin to map into the GUS object model.
> Our inputs will not be larger than what GuS has used in other projects I think,
> but the SQL route could be a good way to go -- I'm not clear on the tradeoffs.
> 
> 
> >  - is the power offered by Bourret's transformer sufficient to justify 
> > us packaging his product with the GUS distribution, which is what we 
> > would probably have to do if we write certified plugins that use it.
> 
> I did not plan to use the existing XMLtoDBMS transformer, in part because
> I'm thinking along the lines of mapping to GUS objects, not DB-SQL, so the
> backends would be different.  Instead the plan is to write a  mapper in the 
> GUS universe using code fragments as possible from existing work 
> by Nick Semenov, who wrote the Perl port of the Java code. 
> Maybe it will be possible to lightly hack XML::XMLtoDBMS and change the backend.
> I plan to look carefully at Semenov's package, which I have used but did not analyze.
> 
> 
> >  - what other third-party software (eg, xml parsers) does bourret 
> > depend on?
> 
> The Perl module XML::XMLtoDBMS uses XML::Parser::PerlSAX;
> 
> 
> 
> >  - since the transform in the case you are handling is so simple, does 
> > it make sense to deploy a third-party transformer rather than just write 
> > some simple brute force perl code
> 
> The mappings are simple, but there are many of them. Another example
> on our end is the retroelement database we are planning for GUS.
> The retroelements will use several tables in addition to NASequeneImp. 
> Without a general strategy, we would need to craft yet another plugin. 
> On the other hand, the XML-to-GUS mapping approach would handle this readily, 
> making for a swift, general-purpose implementation of the retroelement plugin.
> 
> One could conceivably use a single plugin for both our current task (unanchored sequences)
> and the retroelement database. It seems though that the idiosyncracies of GUS objects
> and objects built on GUS objects calls for separate plugins of this type (mappers).
> 
> 
> Terry
> 
> 
> 
> 
> 
> On  0, Steve Fischer <st...@pc...> wrote:
> > Terry-
> > 
> > In general, schema transformation is a hard problem.  It looks like, in 
> > the immediate case, the transform from the agave sequence file to gus is 
> > relatively simple:  a one-to-one transform of a single data type, but 
> > requiring mapping some foreign keys.  It seems that Bourret's XML-DBMS 
> > can handle this gracefully.
> > 
> > What i am not clear on is:
> >  - would this be able to work for the more common, non-trivial case 
> > where the object models differ more significantly?  Angel has done a lot 
> > of thinking about this for his object mapper which maps MAGE-ML into GUS.
> >  - will you go directly to SQL or will you go to gus objects?  In a 
> > simple case like this, it might make sense to go to SQL for efficiency 
> > reasons, if you are expecting huge inputs.
> >  - is the power offered by Bourret's transformer sufficient to justify 
> > us packaging his product with the GUS distribution, which is what we 
> > would probably have to do if we write certified plugins that use it.
> >  - since the transform in the case you are handling is so simple, does 
> > it make sense to deploy a third-party transformer rather than just write 
> > some simple brute force perl code
> >  - what other third-party software (eg, xml parsers) does bourret 
> > depend on?
> > 
> > In sum, i think it is an excellent idea to consider third party 
> > solutions, and to provide general solutions instead of one-off plugins. 
> > I also want to make sure that the extra effort we put into making this a 
> > general solution will have a comensurate payoff.
> > 
> > steve
> > 
> > 
> > Terry Clark wrote:
> > 
> > >Posted for discussion at 
> > >   http://flora.uchicago.edu/ 
> > >is a short specification  sketched (working draft) 
> > >for an XML-to-GUS Plugin for GUS' NASequenceImp, LoadSeqFromXML.pm.
> > >
> > >The idea, based on the XML to DB/SQL work by Ron Bourret,
> > >is to give a flexible way to map various sequence
> > >data management projects into GUS using the same source.
> > >The Plugin operates from 1) an XML formatted sequence file
> > >and 2) a mapping from the sequence file to GUS space. 
> > >
> > >The method is generally applicable to GUS objects/tables,
> > >but the idiosyncracies of objects probably calls for
> > >individual mappers, like  LoadSeqFromXML.pm 
> > >(better named as LoadNASequenceFromXML.pm).  
> > >
> > >Are there any thoughts, variations, existing work, etc.,
> > >about the idea?
> > >
> > >Terry
> > > 
> > >
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > _______________________________________________
> > Gusdev-gusdev mailing list
> > Gus...@li...
> > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev