[ome-devel] OME-XML Java package

[Curtis Rueden]

Hi Harry,

> - Regarding construction of this code, your comment ("10K lines of 
> code  in two weeks "- ouch)  leads me to infer that you did all of 
> this by  hand. Is there any possibility that this code might be 
> auto-generated?  I''m imagining a system similar to that which creates 
> the code for the  current OME-JAVa installation.  It's not the 
> cleanest system, in some  ways, but it does the job...


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.

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.

> - 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?

-Curtis