2007-12-27 Project-wide 3:45 GMT
Attending: Jason, Ilya, Josh, Curtis, Cat
Agenda
- OME-XML
- Bio-Formats 2007 XML schema support status
- Issues with the online OME-XML / OME-TIFF validator
- Internal error if xsi:schemaLocation not defined? (e.g., erroneous use of "schemaLocation" attribute without namespace) — see data/ome-tiff/prairie/SingleImage-12062007-1400-019/ SingleImage-12062007-1400-019_Cycle001_CurrentSettings_Ch1_000001.tif
- Online validator does not display all error messages compared to Bio-Formats command line validator — see data/ome-tiff/volocity/FromVolocity-2007-12-11.ome.tif
- Kevin's proposed changes to Objective
- Should we relax restrictions around Objective parameters (Type, Manufacturer, Correction, Immersion, etc.)? Comment from a developer: "We currently do not store the model or serial number of the objective, nor the Microscope information (which it appears is also required), so I guess we will just have to remove that element for now and put it on the list of things to include in the next version."
- OME-HDF proposal
- OMERO server
- Beta2.3 Released!
- Sha1 checking during import
- Beta2.2 incompatibilities
- Printing out nicer messages than:
- java.io.InvalidClassException: org.jboss.ejb3.session.BaseSessionRemoteProxy ; local class incompatible: stream classdesc serialVersionUID = 2609262789016232311, local class serialVersionUID = 8310915813626447181]
- Website
- Comment from a developer: "I didn't realize there was a newer OME schema. I had been looking at what I thought was the latest version, which is linked from this page: http://www.openmicroscopy.org/api/xml/"
Notes
- OME-XML
- schema support
- Warning (flashing lights, etc.)
- Commit something big to head.
- Week from Monday (7th of January).
- After a bio-formats release.
- Latest version.
- Will break everything.
- Lots of post-commit testing needed.
- Ilya available for testing
- @Curtis emails Brian
- Close to having new schema working in bio-formats
- Fields suported in bio-formats are a small number of fields
- Can flip a switch later to read OME-XML files
- But will only read in the supported fields
- Not doing it the way OME-Perl does it
- Will only map the fields in the mapper
- An extension point doesn't currently exist for OMERO
- How do we handle custom attributes?
- Also don't support all the core types.
- Need to document what the import is leaving out !
- cF. entities.txt: https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/loci/formats/auto/MetadataAutogenEntities.txt
- Warning (flashing lights, etc.)
- validator(s)
- Can Andrew also test with these files? Might be nice to add more information on missing "xsi" in "xsi:schemaLocation"
- Would also be good to cross-reference with the bio-formats command-line tool
- cf. w3c generic validator's "keep going" option. Might be nice to have that. Seems that only first problem is being listed.
- "What's the vision?"
- Who are the customers for the online validator v. commandline validator.
- Java was easy and does a good job
- But a lot of people are going to want to use the web one (haters of CLI)
- Also good to compare the Java and Python facilities for different bugs
- online validator checks OME-TIFF, Java doesn't.
- @Jason writes to Andrews
- Next task
- OME-TIFF and validation type things with companies
- Objective: tabled
- e.g. Correction-color on the lense probably needs an ObjectiveRef
- Relaxing restrictions on Objective
- "Always required? Oh, then I won't do any of it"
- Need to have a better way of determining user needs (more than developer or single opinion)
- "ObjectiveCharacteristic?"
- Whose needs? Users? But we talk to developers.
- Is the statement "we don't care about that" a developer or company/customer opinion?
- Cat: perhaps something that will change over the coming months as the user base changes
- Should support partial information.
- Shouldn't make the perfect enemy of the good
- Possibilities
- 1. New type
- 2. An AbstractObjective super type, which is looser
- 3. Storing incomplete information as quasi-valid OME-XML block
- Whole web2.0 debate ("There's a war goin' on, man")
- Curtis fundamentally wants to get as much information from 3rd party formats into the db.
- Why can't we store wishy-washy information in the db?
- DB reflection of philosophy
- Only way to store it is to remove all nullable information
- Why not?
- > But it doesn't help Curtis solve his problem!
- Curtis is happy with using CustomAttributes
- Just: (1) Unambiguous, (2) No new things/i.e. not too much to learn
- "Incomplete: no LSID for you"
- But also provide disincentive to doing things this way.
- Different name. "ObjectiveFragment"
- Loss of queryability
- Also the Gold star certification is lost with the use of fragments
- schema support
- OME-HDF
- bioformats: seen as a different model
- but using HDF data types?
- Yeah, that's good.
- Have to find a middle ground.
- What's the purpose?
- What of all the abilities do we want to support?
- Who's ready to use it?
- What would we use it for? (Other than just another format)
- Define what we want to do