MPDL AB Meeting 2009-05-27

MPDL  Restricted Access to MPDL
 * Participants:Thomas Endres, Michael Franke, Tobias Schraut, Wilhelm Frank, Natasa Bulatovic

Generic Metadata Handling

 * Architecture
 * see Generic metadata draft
 * see also about DSP in relation to RelaxNG, XML Schema, Schematron --Natasa 19:43, 27 May 2009 (UTC)
 * Maybe would be nice to actually translate DSP definition into Schematron rules ->thus single service for MD validation --Natasa 19:45, 27 May 2009 (UTC)

Outcome
Discussion about whether to use DCAP DSP or not at all?
 * what is the purpose of DSP?
 * Note: there are no tools developed that e.g. validate metadata record based on DSP (AB)
 * are there tools for validation of the metadata records based on DSP?
 * why not using RelaxNG?
 * Note: but what would be the purpose of it - if it serves as replacement for metadata profile xsds? What and how a relation to fine grained validation rules via Validation service? When we were implementing the Validation service this was the reason RelaxNG was discarded--Natasa 19:15, 27 May 2009 (UTC)
 * current screen configuration multiplies the metadata for each screen
 * Note: depends on screen and on solution, not all metadata are repeated on all screens. In addition it depends how a screen configuration is defined and how "readable" is to be for human users. --Natasa 19:15, 27 May 2009 (UTC)
 * there should be single file for metadata and screen configuration
 * As i am reading this, I think it probably is a good idea to also discuss generic metadata with the GUI team. Perhaps they can develop a concept how a the layout for metadata of unknown size could be.--Friederike 06:44, 28 May 2009 (UTC)
 * Yes, is on the list already - as soon as we clarify the underlying concept and implementation. --Natasa 08:54, 28 May 2009 (UTC)


 * Note: we need separate sources for metadata and for screen configurations
 * check ItemScreenBean necessity (Willy mentions there is no need to do it, has to be checked better between Willy and Bastien)

Result: Discussion not closed, to be checked again next meeting

Changes in Publication Metadata Structure

 * event, source, organization, person are handled als "profiles" now (as it is already in colab) the same way like publication and the schema definitions are in separate files
 * enums have an own namespace (see below)
 * all elements under publication, event, source, person, organization, file (not elements from external schemas like dc, dcterms) are in the same NS
 * idtypes are now in escidoc terms NS, too

=Former Topics=

Citation Manager Performance

 * see http://colab.mpdl.mpg.de/mediawiki/Talk:ESciDoc_Services_Search%26Export#Performance_problems
 * General community discussion on JasperReports performance
 * Alternative: XSLT transformation?
 * Upgrade to current JasperReports version?

Read only PubMan

 * http://zim01.gwdg.de:8080/browse/AS-735


 * this does only make sense, if there is some sort of read-only coreservice, right?--Robert 14:28, 9 April 2009 (UTC)

Deployables and Jboss

 * Isolation of ears running on one jboss (possibility to run several solutions on one jboss)
 * Dependencies between deployed ears (pubman -> coreservice in deploy phase)
 * Expected outcome: Find a deployment structure (classpath isolation; bootup order) on jboss which covers actual and future needs

Solution development

 * discussion on pubman deployment and how to approach it
 * discussion on solution properties and how to approach it
 * discussion on service locator issue and how to approach it
 * discussion on development of own policy templates and checking the possibilities to define policies on our own
 * background: more roles coming up with further solution developments
 * see also Talk:ESciDoc_Solutions_summary

EA Documentation

 * issues with the documentation
 * presentation of EA Documentation

Authoriziation issues

 * check http://zim01.gwdg.de:8080/browse/AS-381