Dear PSC members,
I would like to propose to add iso19139 Profil for France support
improving also some ISO profil integration steps (eg. codelist).
The complete proposal is available here [1].
If motion pass, this new feature will be added to GeoNetwork trunk
(for 2.5 release).
This development was first made in the GéoSource sandbox.
Looking forward to your votes, Regards.
Francois & Mathieu
[1] http://trac.osgeo.org/geonetwork/wiki/Iso19139fraSupport
Hi Francois,
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.
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.
Cheers,
Simon
__________________________________
From: Francois Prunayre [fx.prunayre@anonymised.com]
Sent: Wednesday, 7 October 2009 12:27 AM
To: Devel geonetwork-devel@lists.sourceforge.net
Subject: [GeoNetwork-devel] Proposal : iso19139 Profil for France support
Dear PSC members,
I would like to propose to add iso19139 Profil for France support
improving also some ISO profil integration steps (eg. codelist).
The complete proposal is available here [1].
If motion pass, this new feature will be added to GeoNetwork trunk
(for 2.5 release).
This development was first made in the GéoSource sandbox.
Looking forward to your votes, Regards.
Francois & Mathieu
[1] Iso19139fraSupport – GeoNetwork opensource Developer website
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Hi Simon,
2009/10/8 <Simon.Pigot@anonymised.com>:
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).
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.
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.
Cheers.
Francois
Cheers,
Simon
__________________________________
From: Francois Prunayre [fx.prunayre@anonymised.com]
Sent: Wednesday, 7 October 2009 12:27 AM
To: Devel geonetwork-devel@lists.sourceforge.net
Subject: [GeoNetwork-devel] Proposal : iso19139 Profil for France supportDear PSC members,
I would like to propose to add iso19139 Profil for France support
improving also some ISO profil integration steps (eg. codelist).The complete proposal is available here [1].
If motion pass, this new feature will be added to GeoNetwork trunk
(for 2.5 release).This development was first made in the GéoSource sandbox.
Looking forward to your votes, Regards.
Francois & Mathieu
[1] http://trac.osgeo.org/geonetwork/wiki/Iso19139fraSupport
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Hi Francois,
________________________________________
From: Francois Prunayre [fx.prunayre@anonymised.com]
Sent: Thursday, 8 October 2009 8:58 PM
To: Pigot, Simon (CMAR, Hobart)
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Proposal : iso19139 Profil for France support
Hi Simon,
2009/10/8 <Simon.Pigot@anonymised.com>:
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
Hi Simon
2009/10/8 <Simon.Pigot@anonymised.com>:
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?
Maybe it's better to have a java call from the XSL to get the list of
registered schemas and then load the stylesheet for each profil ?
I think there's 2 places to make a change in metadata-utils.xsl :
1) xsl includes
2) the template mode=schema
For 2, maybe we don't really need this template, as the
geonet:info/schema should be defined in all cases ? Not sure about
that one.
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.
True. I have been using the following template to make all profil
element an ISO one which works because we don't have so many
extensions (identification mainly).
<!-- Rename all ISO profil extension -->
<xsl:template match="*[@gco:isoType]" priority="100">
<xsl:element name="{@gco:isoType}">
<xsl:attribute name="namespace">
<!-- FIXME : Add other namespaces ? if needed for profil -->
<xsl:choose>
<xsl:when test="contains(@gco:isoType,
'gmd')">http://www.isotc211.org/2005/gmd</xsl:when>
</xsl:choose>
</xsl:attribute>
<xsl:apply-templates select="*"/>
</xsl:element>
</xsl:template>
so if we have to create a directory for each schema, maybe we should
have it on the schema directory rather than in the xml/csw. That way
we have all in one place ?
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.
True if you ask for a CSW output in the profil, you need a
transformation to do that. We made it for the french profil adding a
xml/csw/iso19139/fra-{brief/summary/full}.xsl.
Ok could you apply this to trunk and I will update fra profil then ?
The idea would be to have
xml/csw/profil-directory/ ?
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?
Yes for Csw.java. In SearchController if we define a common way to
call the profil CSW XSL, it could be removed.
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?
Sounds good to me.
Francois
Cheers and thanks,
Simon
Hi Francois,
I'll take a look at the changes to metadata-utils.xsl to see whether we can do it via the installer or calling java as per your suggestion. I have a feeling that geonet:info/schema may not be in records returned from remote searches hence the template that looks at the root element. We could rationalize this by doing schema detection against known schema in the Z3950Searcher code (this would pick up any profiles known about by the local node) and an unknown value would cause examination of the root element. In short this would remove the need to add the profile to this template, we'd only need to add the include/import for the profile stylesheet.
Also, I'll commit the change to SearchController.java to support the profiles - it uses primary namespace I think as per the fixme comments.
Be next week I reckon along with a couple of other things I have to do Let me know if that holds you up.
Cheers and thanks,
Simon
________________________________________
From: Francois Prunayre [fx.prunayre@anonymised.com]
Sent: Thursday, 8 October 2009 11:47 PM
To: Pigot, Simon (CMAR, Hobart)
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Proposal : iso19139 Profil for France support
Hi Simon
2009/10/8 <Simon.Pigot@anonymised.com>:
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?
Maybe it's better to have a java call from the XSL to get the list of
registered schemas and then load the stylesheet for each profil ?
I think there's 2 places to make a change in metadata-utils.xsl :
1) xsl includes
2) the template mode=schema
For 2, maybe we don't really need this template, as the
geonet:info/schema should be defined in all cases ? Not sure about
that one.
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.
True. I have been using the following template to make all profil
element an ISO one which works because we don't have so many
extensions (identification mainly).
<!-- Rename all ISO profil extension -->
<xsl:template match="*[@gco:isoType]" priority="100">
<xsl:element name="{@gco:isoType}">
<xsl:attribute name="namespace">
<!-- FIXME : Add other namespaces ? if needed for profil -->
<xsl:choose>
<xsl:when test="contains(@gco:isoType,
'gmd')">http://www.isotc211.org/2005/gmd</xsl:when>
</xsl:choose>
</xsl:attribute>
<xsl:apply-templates select="*"/>
</xsl:element>
</xsl:template>
so if we have to create a directory for each schema, maybe we should
have it on the schema directory rather than in the xml/csw. That way
we have all in one place ?
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.
True if you ask for a CSW output in the profil, you need a
transformation to do that. We made it for the french profil adding a
xml/csw/iso19139/fra-{brief/summary/full}.xsl.
Ok could you apply this to trunk and I will update fra profil then ?
The idea would be to have
xml/csw/profil-directory/ ?
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?
Yes for Csw.java. In SearchController if we define a common way to
call the profil CSW XSL, it could be removed.
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?
Sounds good to me.
Francois
Cheers and thanks,
Simon
