Re: [GeoNetwork-devel] Proposal : iso19139 Profil for France support

[<Sim...@cs...>]

Hi Francois,
________________________________________
>From: Francois Prunayre [fx....@gm...]
>Sent: Thursday, 8 October 2009 8:58 PM
>To: Pigot, Simon (CMAR, Hobart)
>Cc: geo...@li...
>Subject: Re: [GeoNetwork-devel] Proposal : iso19139 Profil for France support

>Hi Simon,

>2009/10/8  <Sim...@cs...>:
>> Don't want to be a blocker on this as I'm all in favour of profile support but..... :-)
>>
>> Can you let us know what other changes you will be making to the code (Java and xslt) to support the profile? I would really like to see what improvements for profile support you are going 
>> to make as part of the proposal and whether or not we can work on making profile support sufficiently modular so that profiles can be created as optional installer packs - this means not only
>> doing xslt presentation for the extra elements relating to the profile but making it work in CSW.
>>
>>It will not be sufficiently modular to create independant installer
>>packs, as you still need to include profil specific stylesheet (in
>>metadata-utils.xsl).

Used to be in 2.0.3 that the izpack installer we used then could specify a file in the release as "parseable" and then replace strings like $PROFILE1 with variables set from user input 
during the installer session - seems not unreasonable that we could do this again and do it for metadata-utils.xsl (which is just an xml file after all)? Or too ugly?

>>No change made in Java
>> and only XSL change to retrieve codelists
>>(first in profil, then in iso19139) like we do for labels. 

>>CSW
>>stylesheets is taking care of mapping an ISO profil metadata record to
>>an ISO so CSW should work with any profils.

Yep its really good - I have a few comments about profile support though:

I think the basis of the xslt that produces the brief/summary/full element sets for IsoRecord is to assume the presence of the ISO element or a profile element with gco:isoType attribute set to that element - unfortunately this makes for very ugly xslt and not all elements in the existing brief/summary xslts have the gco:isoType attribute match (and it would be tedious to add it too) - so for example the supplied xslts don't produce all the output they should with the Marine Community Profile. Also one set of xslts cannot produce output for elements that are in the profile and not in the base ISO standard. We've found it necessary to add brief/summary/full xslts for each profile we support and made a small change to SearchController.java to choose the profile specific directory in the csw stuff to find these xslts.

I think there are still a few references to the French profile in the CSW code (SearchController.java and a namespace in csw/common/Csw.java) and csw-config.xml last time I looked (sorry for being picky here :-)) but I'm not sure whether they are necessary as profile support seemed to work for our profiles without these mods?

>> If we aren't going to make profiles into installer packs then why can't people interested in adding a profile just look in the sandboxes to find an example profile (eg. ISO Profile for France is in 
>>GeoSource and Marine Community Profile etc is in BlueNetMEST)? Anybody adding a profile would need to know quite a bit about GeoNetwork - certainly enough to navigate the sandboxes.
>The main issue on this, is that GéoSource sandbox is not fully align
>to trunk, so you can not get the profil from that sandbox and put in
>the trunk as it is. So that's why I would like to have it on trunk
>working well with all trunk latest features because sometime we're
>making projects based on trunk and sometimes on GéoSource according to
>the needs.
>If you want to add the profil, you still have to dig in some XSL to
>plug it in. So if the schema is loaded, then users could only load a
>template to start working with it.

>If we don't want the profil to be loaded by default, we could create
>an xml/otherschemas folder in order to store a maintained and
>supported schema. The metadata-iso19139.profil.xsl will be in the xsl
>folder.

Yep - fair enough - we could have a procedure like language support: the maintainer of the profile would be responsible for making sure their profile continued to function before a release was done. This would remove the burden of testing all the different profiles from developers making changes to core functions?

Cheers and thanks,
Simon