On Wed, 17 Nov 2004, Mark Gibson wrote:
> We are about to embark on full read and write of chado xml, but there are some
> issues with macros that really need to be resolved.
> Pinglei - so xort currently dumps out chado xml from the database with no
> macros. Can it also dump chado xml with macros - I guess with some standard set
> of macros? My sense from our discussions is that it currently does not do that,
> but I could be wrong.
I'm guessing it dumps without. However, I (think I) could knock up a short
XSL transformation that would macro-ize ChadoXML. This transformation
would be seamless from the pov of apollo by using something like xalan.jar
> If xort only dumps full chado xml with no macros, then apollos reader would of
> course read unmacro'd chado. If apollo can only read unmacro'd chado then the
> writer better only write out unmacro'd chado, as it better be writing something
> the reader can read. So if all of this is the case than macros become a moot
> point for both the reader and writer.
> Guanming has already written a bunch of chado xml writing apollo code thats
> writing chado transaction xml. Writing a full chado xml writer would ideally
> resuse a lot of his code as just about all of the transaction chado xml would
> obviously go in the full chado xml (minus the ops, plus some non-transaction stuff).
> Im pretty sure Guanming's code is using macros for writing out this chado
> xml(guanming?). Therefore if we cant use macros for full read and write we
> either cant use guanmings stuff and write stuff from scratch or we rewrite it to
> use full verbose chado xml (which would be a bummer).
> We could have both macro'd and unmacrod readers and writers but that seems silly
> and overkill.
I'm not really in the guts of the code writing here, but I don't think
this would be overkill at all
IMHO the code should be written to read un-macroized ChadoXML; it should
then be trivial to expand macros at parse time - either to the expanded
xml or to a cached java object reference
The adaptor should definitely not expect macro-ized ChadoXML - any more
than a C compiler should expect to find a given set of macros in a C
program. This approach is doomed to failure, as in theory anything can be
macro-ized, as the xort macro mechanism is completely generic.
The disadvantage of this approach is that it may be slightly slower - I do
feel this is the right way to go though (though like I say I'm not writing
the code here, just pontificating from the outside)
> So if xort can dump chadoxml with macros then the above problems are greatly
> lessened - we just need to make sure to use the same macros. If not how would
> people feel about adding this ability as an option to xort? I dont know whats
> best, to have standard macroing as a builtin option (the default would still be
> unmacroed) or be able to attach a file of macros to use or whatever?
> Pinglei how hard would it be to add macros on xort dump (if its not there
> already) and would you consider this a worthwhile endeavor?
> Guanming - how hard would it be to change your stuff to not use macros at all?
> Frank - did C2G read unmacro'd chado xml and did G2C write macro'd of unmacro'd
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. http://www.intersystems.com/match8
> Gmod-chado-seq-ad mailing list