Apache SIS metadata objects can represent themselves as a java.util.Map
view or a tree. Up to now, those views were matching almost exactly the
Java interfaces. But now we have a mismatch between the Java interfaces
used by trunk (ISO 19115:2003) and the model partially available in
Apache SIS (ISO 19115:2014). Which model should we show in Map views,
tree views and string representations?
Examples: a small metadata block according ISO 19115:2003 model (the one
currently shown by Apache SIS trunk):
Citation
??Title...................................................... European
Petroleum Survey Group
??Cited responsible party
? ??Organisation name...... Oil and Gas Producers
? ??Contact info
? ? ??Online resource
? ? ??Linkage............ http://www.epsg.org
? ? ??Function......... Information
? ??Role............................................. Principal
investigator
??Presentation form.................. Table digital
The same metadata block according ISO 19115:2014 model (the one
currently shown by Apache SIS branches):
Citation
??Title..................................................................
European Petroleum Survey Group
??Cited responsible party
? ??Role.........................................................
Principal investigator
? ??Party
? ??Organisation name...... Oil and Gas Producers
? ??Contact info
? ??Online resource
? ??Linkage............ http://www.epsg.org
? ??Function......... Information
??Presentation form.............................. Table digital
The differences are small (the new model has an additional "Party"
node). Which model to show?
1. If Apache SIS trunk show the old model, we will still have a simple
relationship between the views and the Java interface used by trunk.
But we would have difference between the models used by the trunk
and the branches.
2. If Apache SIS trunk show the new model, we will have more
consistency between the trunk and the branches and users can start
getting familiar with the new model. But users may be confused by
the fact that the views (tree, map) do not match exactly the Java
interfaces (until we get a new GeoAPI release).
What would peoples prefer?
Martin
