[ome-devel] OME-XML Java package

[Harry Hochheiser]

Curtis:

> Yes, I did it by hand, but created a couple of macros to speed things 
> along very quickly. It would certainly be possible to auto-generate a 
> lot of the code. To be honest, when I first started, I did not fully 
> understand how certain OME constructs were represented in XML, 
> although Ilya clarified it for me when I asked about LogicalChannel vs 
> ChannelInfo. In retrospect, I should not have abandoned the OME-CA 
> stylesheets; I did not realize that certain information could be split 
> between schema elements and ST elements.
>
Fair enough. Even when these things can be automated, it's often useful 
to do them by hand once to help understand the issues..

> For the next revision of the package, I plan to switch back to using 
> stylesheets. The code would work pretty much the same as it does now, 
> and it would cut down on some complexity and thus potential bugs. It 
> also avoids reading in BinData as part of the DOM, which is 
> prohibitive.
>
> The next revision will also handle pixel extraction, using SAX to 
> efficiently grab only the requested BinData block(s) from disk on 
> demand to save memory.
>
> Lastly, I will investigate autogenerating as much of the code as 
> possible. Now that I understand more details (how most schema elements 
> have ST equivalents, etc.) I realize it is easier than I originally 
> thought to use the ST definitions as a basis for code generation.


Sounds great in general.

Regarding autogeneration of the code, it's probably worth looking at 
the code generation for the ds.dto and ds.st package in OME-JAVA. The 
omejava script (in the main ome distribution, under src/perl2/OME/Java) 
builds the OME-Java code by looking at either hashes found in external 
files (under ./dto-src in the OME-JAVA dist) or at declarations in the 
database (for STs). Based on these, it writes out the code.

It might not be terribly hard to modify/extend this code to spit out 
your OME-XML parsing code.

(I should note here that this code generation approach is far from 
optimal, and should probably be redesigned altogether).

>> - In terms of packaging, it's clear that "OME-JAVA" is a name that 
>> we'd  love to change. I wonder if we should change the name to  
>> org.openmicroscopy.xml and distribute it as a separate package. At 
>> some  level, this becomes a policy question: do we want lots of 
>> small,  focused jars, or a smaller number of jars with broader 
>> functionality?  Personally, I favor splitting things up..
>
>
> Since my XML package is very similar to the Java remote framework, 
> implementing the same interfaces, I think it makes sense to include 
> both in a single library. The XML package depends on 
> org.openmicroscopy.ds.dto and org.openmicroscopy.ds.st either way, and 
> an extra 100K added to ome-java.jar is not a big deal. Also, why do 
> you think the name "OME-JAVA" should be changed?
>

fair enough - I can see both sides of the argument. OME-JAVA is a name 
that's altogether too vague. I'd personally prefer names that carry 
functional specificity..

-harry