• Architecture discussion

XML binding

• [heikki] XML binding: In the ebRIM branch, and in the Nordic Security code (not public yet), JiBX is used for Java <--> XML binding. It is highly useful to have such a binding, as it can be invoked automatically on Web Service communications and leads to a much cleaner dealing with objects in Java than when DOM/JDOM is used. One disadvantage of JiBX is that this binding needs to be written manually, which is a bit of a pain in the neck. Another disadvantage is that it is not a Java standard. JAXB on the other hand *is* the standard and comes with a binding-generator that takes a schema and produces the bound Java classes.

However, I've tried running it on the ISO19139 schema and it does not work :

~/jaxb-ri-20110115/bin$ xjc -p testpackagename ~/source/ogc/ogc-schemas/trunk/iso/19139/20070417/schema/src/main/resources/iso/19139/20070417/gmd/gmd.xsd

The result is :

parsing a schema...
[ERROR] Property "Rows" is already defined. Use <jaxb:property> to resolve this conflict.
 line 648 of file:
~/source/ogc/ogc-schemas/trunk/iso/19139/20070417/schema/src/main/resources/gml/3.2.1/geometryPrimitives.xsd

[ERROR] The following location is relevant to the above error
 line 680 of file:
~/source/ogc/ogc-schemas/trunk/iso/19139/20070417/schema/src/main/resources/gml/3.2.1/geometryPrimitives.xsd

Failed to parse a schema.

This is because of peculiarities in the schemas that we cannot control. I have asked users@ogc.java.net if it is possible to do this at all, but I'd be surprised.

Question remains: if we cannot use JAXB to generate a binding for ISO19139, is it still desired to use JAXB for situations where we *can* use it, instead of using JiBX ?

UPDATE

Generated classes representing the OGC schemas are available, after all (see ​http://confluence.highsource.org/display/OGCS/Reference).

So the new question is: do we like to replace DM/JDOM code with these ?

DB

• DB / Mckoi to H2 or HSQL or derby ? See #475

Search and Lucene index

• Lucene
  • Merge LQB and lucene XSLTs (See #480)
    • Add any search criteria
    • Search param is one value or an array value
  • Thread for indexing ?
  • IndexWriter alert IndexReader about status

[heikki] Don't think this is necessary in Geonetwork code; code should already use only 1 IndexReader that should re-open itself only when necessary.

• Search
  • Return JSON
  • Using only stored field from the index #485
  • StandardAnalyzer & GeoNetworkAnalyzer :
    • Removed character like (';,)} at the end/start of tokens #476
    • Chinese was not tokenized by GeoNetworkAnalyzer #476
    • Comment:
      • StandardAnalyzer keep accent, do not keep negative number, split dates after hour

[heikki] Improvements to GeoNetworkAnalyzer so it has all the goodies of StandardAnalyzer, e.g. does tokenize Chinese and does not keep brackets and commas at the end of tokens, without breaking wildcard search and has added accented-character-abstraction, #476

• SOLR

Profiles

• Schema detection improvements #481

Code

• Simplify #477, #479
  • SettingManager (lock, default value),
  • DataManager, #430
  • XMLSerializer #430

Performance improvements

• root/gui/localized - only current session language ? - faster XSL
• DB queries

Misc.

• Maven : version settings heikki: Jose suggest use sed; but that is os-dependent and Maven could do it too, it is said
• Harvester [heikki: pending Mathieu's code about this]