[GeoNetwork-devel] CSW / Xpath / ElementName issue on dc:date

GeoNetwork GeoNetwork Developer
1

Hi,

Given the issue I mentioned in my other e-mail (see : http://osgeo-org.1803224.n2.nabble.com/CSW-and-Xpath-on-ElementName-MD-Keywords-issue-td6603029.html) I tried to find a workaround using Dublin Core in our CSW web development.

Looking at http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd, I asked for the dc:date element in the request but
<csw:ElementName>dc:date</csw:ElementName>
does not work. Neither dc:creator, dc:description, dc:publisher, dc:contributor (for creator/publisher/contributor I tested with metadata having the expected values).

Whereas others from 'Table 9 - Mapping to common returnable properties' (07-045 OpenGIS_Catalogue_Services Specification) seem to work

Any idea why ?

Compared to the other thread, what is weird it that here :
<csw:ElementName>dc:subject</csw:ElementName>
provides all the Keywords stored

I am running a GN 2.6.0 with metadata done using the 'Template for Vector data in ISO 19139 (preferred!)' (of a 2.6.0 RC1).
Address: http://services.sandre.eaufrance.fr/geonetwork_CSW/srv/en/csw
Sample CSW Query :

<csw:GetRecords xmlns:csw="http://www.opengis.net/cat/csw/2.0.2&quot; xmlns:dc="http://purl.org/dc/elements/1.1/&quot; service="CSW" version="2.0.2" resultType="results" startPosition="1" maxRecords="20" >
<csw:Query typeNames="csw:Record">
<csw:ElementName>dc:identifier</csw:ElementName>
<csw:ElementName>dc:title</csw:ElementName>
<csw:ElementName>dc:date</csw:ElementName>
<ogc:SortBy xmlns:ogc="http://www.opengis.net/ogc&quot;&gt;
<ogc:SortProperty>
<ogc:PropertyName>relevance</ogc:PropertyName>
<ogc:SortOrder>D</ogc:SortOrder>
</ogc:SortProperty>
</ogc:SortBy>
<csw:Constraint version="1.0.0">
<ogc:Filter xmlns:ogc="http://www.opengis.net/ogc&quot;&gt;
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>AnyText</ogc:PropertyName>
<ogc:Literal>stations</ogc:Literal>
</ogc:PropertyIsEqualTo>
<ogc:And>
<ogc:Intersects>
<ogc:PropertyName>ows:BoundingBox</ogc:PropertyName>
<gml:Box xmlns:gml="http://www.opengis.net/gml&quot;&gt;
<gml:coordinates decimal="." cs="," ts=" ">-180,-90 180,90</gml:coordinates>
</gml:Box>
</ogc:Intersects>
</ogc:And>
</ogc:Filter>
</csw:Constraint>
</csw:Query>
</csw:GetRecords>

Sylvain

2

Hi Sylvain,

On 07/21/2011 07:56 PM, Sylvain Grellet wrote:

Hi,

Given the issue I mentioned in my other e-mail (see :
http://osgeo-org.1803224.n2.nabble.com/CSW-and-Xpath-on-ElementName-MD-Keywords-issue-td6603029.html)

This issue appears to be a limitation of the XPath code in Jeeves that we are using - it only returns one element (the first one if there is more than one) - it should be enhanced to return a list if there is more than one element that matches the XPath. Not hard to do I think - I'll take a look shortly if no one else is doing this already.

I tried to find a workaround using Dublin Core in our CSW web development.

Looking at http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd, I
asked for the dc:date element in the request but
<csw:ElementName>dc:date</csw:ElementName>
does not work. Neither dc:creator, dc:description, dc:publisher,
dc:contributor (for creator/publisher/contributor I tested with metadata
having the expected values).

Whereas others from 'Table 9 - Mapping to common returnable properties'
(07-045 OpenGIS_Catalogue_Services Specification) seem to work

Any idea why ?

Not sure why the dc: ones you tried above didn't work. I'll take a look when investigating the above (again, if no one else is doing that already).

Compared to the other thread, what is weird it that here :
<csw:ElementName>dc:subject</csw:ElementName>
provides all the Keywords stored

Looking at the code, this is because XPaths are not used on CSW-discovery responses - this metadata format is not nested so the code simply removes all elements in the response record that don't match the ones you specified as ElementNames - so that's why you get all the keywords/dc:subject elements.

Cheers and thanks,
Simon

3

Hi Simon,

Thanks for your quick reply.
Concerning Jeeves, ticket 492 (http://trac.osgeo.org/geonetwork/ticket/492) mentions :
"A proposed fix for this is to replace the handling of ElementName parameters to no longer use the Jeeves Xpath class, and instead generate an XSLT on the fly that contains".
It's not the same issue than mine but at least, mentions a possible common solution.

Apparently it's fixed and in 2.6.4.
Not sure if the fix applied is getting rid of Jeeves Xpath class or something else.

Sylvain

Le 21/07/2011 12:47, Simon Pigot a écrit :

Hi Sylvain,

On 07/21/2011 07:56 PM, Sylvain Grellet wrote:

Hi,

Given the issue I mentioned in my other e-mail (see :
http://osgeo-org.1803224.n2.nabble.com/CSW-and-Xpath-on-ElementName-MD-Keywords-issue-td6603029.html)

This issue appears to be a limitation of the XPath code in Jeeves that we are using - it only returns one element (the first one if there is more than one) - it should be enhanced to return a list if there is more than one element that matches the XPath. Not hard to do I think - I'll take a look shortly if no one else is doing this already.

I tried to find a workaround using Dublin Core in our CSW web development.

Looking at http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd, I
asked for the dc:date element in the request but
<csw:ElementName>dc:date</csw:ElementName>
does not work. Neither dc:creator, dc:description, dc:publisher,
dc:contributor (for creator/publisher/contributor I tested with metadata
having the expected values).

Whereas others from 'Table 9 - Mapping to common returnable properties'
(07-045 OpenGIS_Catalogue_Services Specification) seem to work

Any idea why ?

Not sure why the dc: ones you tried above didn't work. I'll take a look when investigating the above (again, if no one else is doing that already).

Compared to the other thread, what is weird it that here :
<csw:ElementName>dc:subject</csw:ElementName>
provides all the Keywords stored

Looking at the code, this is because XPaths are not used on CSW-discovery responses - this metadata format is not nested so the code simply removes all elements in the response record that don't match the ones you specified as ElementNames - so that's why you get all the keywords/dc:subject elements.

Cheers and thanks,
Simon

4

Great! Thanks. From ticket 492 it looks like the Jeeves XPath class has other issues, so an alternative was required. I can see the change to an XSLT in 2.6.x (it's rev 7565) but not in trunk (which is what confused me). Now that the schema plugins are in the trunk, I wonder whether for trunk we could avoid coding the XSLT in Java and instead use the JAXP XPath class (through methods in jeeves.utils.Xml) preloaded with the namespaces from the appropriate metadata schema? As it happens I need this function to work in a CSW client so I'll take a look at that instead :-).

Cheers and thanks again,
Simon
________________________________________
From: Sylvain Grellet [s.grellet@anonymised.com]
Sent: Thursday, 21 July 2011 10:10 PM
To: Simon Pigot
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] CSW / Xpath / ElementName issue on dc:date

Hi Simon,

Thanks for your quick reply.
Concerning Jeeves, ticket 492
(#492 (CSW 2.0.2 ElementName processing broken) – GeoNetwork opensource Developer website) mentions :
"A proposed fix for this is to replace the handling of ElementName
parameters to no longer use the Jeeves Xpath class, and instead generate
an XSLT on the fly that contains".
It's not the same issue than mine but at least, mentions a possible
common solution.

Apparently it's fixed and in 2.6.4.
Not sure if the fix applied is getting rid of Jeeves Xpath class or
something else.

Sylvain

Le 21/07/2011 12:47, Simon Pigot a écrit :

Hi Sylvain,

On 07/21/2011 07:56 PM, Sylvain Grellet wrote:

Hi,

Given the issue I mentioned in my other e-mail (see :
http://osgeo-org.1803224.n2.nabble.com/CSW-and-Xpath-on-ElementName-MD-Keywords-issue-td6603029.html)

This issue appears to be a limitation of the XPath code in Jeeves that
we are using - it only returns one element (the first one if there is
more than one) - it should be enhanced to return a list if there is
more than one element that matches the XPath. Not hard to do I think -
I'll take a look shortly if no one else is doing this already.

I tried to find a workaround using Dublin Core in our CSW web
development.

Looking at http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd, I
asked for the dc:date element in the request but
<csw:ElementName>dc:date</csw:ElementName>
does not work. Neither dc:creator, dc:description, dc:publisher,
dc:contributor (for creator/publisher/contributor I tested with metadata
having the expected values).

Whereas others from 'Table 9 - Mapping to common returnable properties'
(07-045 OpenGIS_Catalogue_Services Specification) seem to work

Any idea why ?

Not sure why the dc: ones you tried above didn't work. I'll take a
look when investigating the above (again, if no one else is doing that
already).

Compared to the other thread, what is weird it that here :
<csw:ElementName>dc:subject</csw:ElementName>
provides all the Keywords stored

Looking at the code, this is because XPaths are not used on
CSW-discovery responses - this metadata format is not nested so the
code simply removes all elements in the response record that don't
match the ones you specified as ElementNames - so that's why you get
all the keywords/dc:subject elements.

Cheers and thanks,
Simon

------------------------------------------------------------------------------
5 Ways to Improve & Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net

GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

5

Ok great.

If you happen to find the issue behind the dc:date one as well, tell me.
Having xslt done on the client side would be lighter with dc: outputs rather than full ISO 19139.

Thanks.

Sylvain

Le 21/07/2011 15:05, Simon.Pigot@anonymised.com a écrit :

Great! Thanks. From ticket 492 it looks like the Jeeves XPath class has other issues, so an alternative was required. I can see the change to an XSLT in 2.6.x (it's rev 7565) but not in trunk (which is what confused me). Now that the schema plugins are in the trunk, I wonder whether for trunk we could avoid coding the XSLT in Java and instead use the JAXP XPath class (through methods in jeeves.utils.Xml) preloaded with the namespaces from the appropriate metadata schema? As it happens I need this function to work in a CSW client so I'll take a look at that instead :-).

Cheers and thanks again,
Simon
________________________________________
From: Sylvain Grellet [s.grellet@anonymised.com]
Sent: Thursday, 21 July 2011 10:10 PM
To: Simon Pigot
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] CSW / Xpath / ElementName issue on dc:date

Hi Simon,

Thanks for your quick reply.
Concerning Jeeves, ticket 492
(http://trac.osgeo.org/geonetwork/ticket/492) mentions :
"A proposed fix for this is to replace the handling of ElementName
parameters to no longer use the Jeeves Xpath class, and instead generate
an XSLT on the fly that contains".
It's not the same issue than mine but at least, mentions a possible
common solution.

Apparently it's fixed and in 2.6.4.
Not sure if the fix applied is getting rid of Jeeves Xpath class or
something else.

Sylvain

Le 21/07/2011 12:47, Simon Pigot a écrit :

Hi Sylvain,

On 07/21/2011 07:56 PM, Sylvain Grellet wrote:

Hi,

Given the issue I mentioned in my other e-mail (see :
http://osgeo-org.1803224.n2.nabble.com/CSW-and-Xpath-on-ElementName-MD-Keywords-issue-td6603029.html)

This issue appears to be a limitation of the XPath code in Jeeves that
we are using - it only returns one element (the first one if there is
more than one) - it should be enhanced to return a list if there is
more than one element that matches the XPath. Not hard to do I think -
I'll take a look shortly if no one else is doing this already.

I tried to find a workaround using Dublin Core in our CSW web
development.

Looking at http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd, I
asked for the dc:date element in the request but
<csw:ElementName>dc:date</csw:ElementName>
does not work. Neither dc:creator, dc:description, dc:publisher,
dc:contributor (for creator/publisher/contributor I tested with metadata
having the expected values).

Whereas others from 'Table 9 - Mapping to common returnable properties'
(07-045 OpenGIS_Catalogue_Services Specification) seem to work

Any idea why ?

Not sure why the dc: ones you tried above didn't work. I'll take a
look when investigating the above (again, if no one else is doing that
already).

Compared to the other thread, what is weird it that here :
<csw:ElementName>dc:subject</csw:ElementName>
provides all the Keywords stored

Looking at the code, this is because XPaths are not used on
CSW-discovery responses - this metadata format is not nested so the
code simply removes all elements in the response record that don't
match the ones you specified as ElementNames - so that's why you get
all the keywords/dc:subject elements.

Cheers and thanks,
Simon

------------------------------------------------------------------------------
5 Ways to Improve& Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
_______________________________________________
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

6

Quick feedback after having deployed the 2.6.4.

- The xPath bug is not there anymore when using expressions like (cf http://osgeo-org.1803224.n2.nabble.com/CSW-and-Xpath-on-ElementName-MD-Keywords-issue-td6603029.html) :
<csw:ElementName>/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:descriptiveKeywords/gmd:MD_Keywords</csw:ElementName>
I retrieve all the necessary Keywords or CI_OnlineResource elements.

- But the issue with dc:date is still there :frowning:

Thanks Simon for having identified what was done under rev 7565.

Sylvain

Le 21/07/2011 15:11, Sylvain Grellet a écrit :

Ok great.

If you happen to find the issue behind the dc:date one as well, tell me.
Having xslt done on the client side would be lighter with dc: outputs
rather than full ISO 19139.

Thanks.

Sylvain

Le 21/07/2011 15:05, Simon.Pigot@anonymised.com a écrit :

Great! Thanks. From ticket 492 it looks like the Jeeves XPath class has other issues, so an alternative was required. I can see the change to an XSLT in 2.6.x (it's rev 7565) but not in trunk (which is what confused me). Now that the schema plugins are in the trunk, I wonder whether for trunk we could avoid coding the XSLT in Java and instead use the JAXP XPath class (through methods in jeeves.utils.Xml) preloaded with the namespaces from the appropriate metadata schema? As it happens I need this function to work in a CSW client so I'll take a look at that instead :-).

Cheers and thanks again,
Simon
________________________________________
From: Sylvain Grellet [s.grellet@anonymised.com]
Sent: Thursday, 21 July 2011 10:10 PM
To: Simon Pigot
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] CSW / Xpath / ElementName issue on dc:date

Hi Simon,

Thanks for your quick reply.
Concerning Jeeves, ticket 492
(http://trac.osgeo.org/geonetwork/ticket/492) mentions :
"A proposed fix for this is to replace the handling of ElementName
parameters to no longer use the Jeeves Xpath class, and instead generate
an XSLT on the fly that contains".
It's not the same issue than mine but at least, mentions a possible
common solution.

Apparently it's fixed and in 2.6.4.
Not sure if the fix applied is getting rid of Jeeves Xpath class or
something else.

Sylvain

Le 21/07/2011 12:47, Simon Pigot a écrit :

Hi Sylvain,

On 07/21/2011 07:56 PM, Sylvain Grellet wrote:

Hi,

Given the issue I mentioned in my other e-mail (see :
http://osgeo-org.1803224.n2.nabble.com/CSW-and-Xpath-on-ElementName-MD-Keywords-issue-td6603029.html)

This issue appears to be a limitation of the XPath code in Jeeves that
we are using - it only returns one element (the first one if there is
more than one) - it should be enhanced to return a list if there is
more than one element that matches the XPath. Not hard to do I think -
I'll take a look shortly if no one else is doing this already.

I tried to find a workaround using Dublin Core in our CSW web
development.

Looking at http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd, I
asked for the dc:date element in the request but
<csw:ElementName>dc:date</csw:ElementName>
does not work. Neither dc:creator, dc:description, dc:publisher,
dc:contributor (for creator/publisher/contributor I tested with metadata
having the expected values).

Whereas others from 'Table 9 - Mapping to common returnable properties'
(07-045 OpenGIS_Catalogue_Services Specification) seem to work

Any idea why ?

Not sure why the dc: ones you tried above didn't work. I'll take a
look when investigating the above (again, if no one else is doing that
already).

Compared to the other thread, what is weird it that here :
<csw:ElementName>dc:subject</csw:ElementName>
provides all the Keywords stored

Looking at the code, this is because XPaths are not used on
CSW-discovery responses - this metadata format is not nested so the
code simply removes all elements in the response record that don't
match the ones you specified as ElementNames - so that's why you get
all the keywords/dc:subject elements.

Cheers and thanks,
Simon

------------------------------------------------------------------------------
5 Ways to Improve& Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
_______________________________________________
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

------------------------------------------------------------------------------
5 Ways to Improve& Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
_______________________________________________
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

7

Hi Sylvain,

dc:date should be working now in trunk - the mapping from gmd:dateStamp was missing for iso19139 and profiles (you can add it yourself to web/geonetwork/xml/csw/schemas/iso19139/ogc-full.xsl to get it working).

Also checked into the other common returnables (in trunk) that you mentioned: found that all were working except dc:description which should map to gmd:identificationInfo/*/gmd:abstract. This was being returned as dct:abstract - which actually seems more logical to me - it's now also being returned as dc:description so we're in agreement with table 9 in the CSW standard.

The csw:ElementName XPath support has also been upgraded in trunk (rev 8037) using the XPath processing methods from jeeves.utils.Xml with any namespaces used in the XPath loaded from a list built when parsing the metadata schema. This should make it more flexible in handling ISO profiles than the Java encoded XSLT in 2.6.4. eg. The following GetRecords query has a csw:ElementName that includes Marine Community Profile (MCP) namespaces:

<csw:GetRecords xmlns:csw="http://www.opengis.net/cat/csw/2.0.2&quot; xmlns:dc="DCMI: DCMI Metadata Terms; service="CSW" version="2.0.2" resultType="results_with_summary" startPosition="1" maxRecords="20" outputSchema="csw:IsoRecord">
  <csw:Query typeNames="csw:Record">
  <csw:ElementName>gmd:identificationInfo/mcp:MD_DataIdentification/gmd:extent/mcp:EX_Extent/mcp:taxonomicElement</csw:ElementName>
  <csw:Constraint version="1.0.0">
    <ogc:Filter xmlns:ogc="http://www.opengis.net/ogc&quot;&gt;
      <ogc:PropertyIsLike wildCard="%" singleChar="_" escape="\">
        <ogc:PropertyName>AnyText</ogc:PropertyName>
        <ogc:Literal>%Beekeeping%</ogc:Literal>
      </ogc:PropertyIsLike>
     </ogc:Filter>
  </csw:Constraint>
  </csw:Query>
</csw:GetRecords>

(Response is attached).

The same XPath approach is used for both csw:Record and csw:IsoRecord output schemas now so you should be able to use XPath syntax in either output.

Cheers and thanks for the detailed bug report/query!
Simon
________________________________________
From: Sylvain Grellet [s.grellet@anonymised.com]
Sent: Saturday, 23 July 2011 1:51 AM
To: Sylvain GRELLET
Cc: Pigot, Simon (CMAR, Hobart); Simon.Pigot@anonymised.com; geonetwork-devel@anonymised.comsts.sourceforge.net
Subject: Re: [GeoNetwork-devel] CSW / Xpath / ElementName issue on dc:date

Quick feedback after having deployed the 2.6.4.

- The xPath bug is not there anymore when using expressions like (cf
http://osgeo-org.1803224.n2.nabble.com/CSW-and-Xpath-on-ElementName-MD-Keywords-issue-td6603029.html)
:
<csw:ElementName>/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:descriptiveKeywords/gmd:MD_Keywords</csw:ElementName>
I retrieve all the necessary Keywords or CI_OnlineResource elements.

- But the issue with dc:date is still there :frowning:

Thanks Simon for having identified what was done under rev 7565.

Sylvain

Le 21/07/2011 15:11, Sylvain Grellet a écrit :

Ok great.

If you happen to find the issue behind the dc:date one as well, tell me.
Having xslt done on the client side would be lighter with dc: outputs
rather than full ISO 19139.

Thanks.

Sylvain

Le 21/07/2011 15:05, Simon.Pigot@anonymised.com a écrit :

Great! Thanks. From ticket 492 it looks like the Jeeves XPath class has other issues, so an alternative was required. I can see the change to an XSLT in 2.6.x (it's rev 7565) but not in trunk (which is what confused me). Now that the schema plugins are in the trunk, I wonder whether for trunk we could avoid coding the XSLT in Java and instead use the JAXP XPath class (through methods in jeeves.utils.Xml) preloaded with the namespaces from the appropriate metadata schema? As it happens I need this function to work in a CSW client so I'll take a look at that instead :-).

Cheers and thanks again,
Simon
________________________________________
From: Sylvain Grellet [s.grellet@anonymised.com]
Sent: Thursday, 21 July 2011 10:10 PM
To: Simon Pigot
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] CSW / Xpath / ElementName issue on dc:date

Hi Simon,

Thanks for your quick reply.
Concerning Jeeves, ticket 492
(#492 (CSW 2.0.2 ElementName processing broken) – GeoNetwork opensource Developer website) mentions :
"A proposed fix for this is to replace the handling of ElementName
parameters to no longer use the Jeeves Xpath class, and instead generate
an XSLT on the fly that contains".
It's not the same issue than mine but at least, mentions a possible
common solution.

Apparently it's fixed and in 2.6.4.
Not sure if the fix applied is getting rid of Jeeves Xpath class or
something else.

Sylvain

Le 21/07/2011 12:47, Simon Pigot a écrit :

Hi Sylvain,

On 07/21/2011 07:56 PM, Sylvain Grellet wrote:

Hi,

Given the issue I mentioned in my other e-mail (see :
http://osgeo-org.1803224.n2.nabble.com/CSW-and-Xpath-on-ElementName-MD-Keywords-issue-td6603029.html)

This issue appears to be a limitation of the XPath code in Jeeves that
we are using - it only returns one element (the first one if there is
more than one) - it should be enhanced to return a list if there is
more than one element that matches the XPath. Not hard to do I think -
I'll take a look shortly if no one else is doing this already.

I tried to find a workaround using Dublin Core in our CSW web
development.

Looking at http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd, I
asked for the dc:date element in the request but
<csw:ElementName>dc:date</csw:ElementName>
does not work. Neither dc:creator, dc:description, dc:publisher,
dc:contributor (for creator/publisher/contributor I tested with metadata
having the expected values).

Whereas others from 'Table 9 - Mapping to common returnable properties'
(07-045 OpenGIS_Catalogue_Services Specification) seem to work

Any idea why ?

Not sure why the dc: ones you tried above didn't work. I'll take a
look when investigating the above (again, if no one else is doing that
already).

Compared to the other thread, what is weird it that here :
<csw:ElementName>dc:subject</csw:ElementName>
provides all the Keywords stored

Looking at the code, this is because XPaths are not used on
CSW-discovery responses - this metadata format is not nested so the
code simply removes all elements in the response record that don't
match the ones you specified as ElementNames - so that's why you get
all the keywords/dc:subject elements.

Cheers and thanks,
Simon

------------------------------------------------------------------------------
5 Ways to Improve& Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at GeoNetwork - Geographic Metadata Catalog download | SourceForge.net

------------------------------------------------------------------------------
5 Ways to Improve& Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
_______________________________________________
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

(attachments)

getr.out.xml (17.7 KB)

8

Hi Simon,

Works fine now.
Thanks for the support.

Sylvain

Le 23/07/2011 03:44, Simon.Pigot@anonymised.com a écrit :

Hi Sylvain,

dc:date should be working now in trunk - the mapping from gmd:dateStamp was missing for iso19139 and profiles (you can add it yourself to web/geonetwork/xml/csw/schemas/iso19139/ogc-full.xsl to get it working).

Also checked into the other common returnables (in trunk) that you mentioned: found that all were working except dc:description which should map to gmd:identificationInfo/*/gmd:abstract. This was being returned as dct:abstract - which actually seems more logical to me - it's now also being returned as dc:description so we're in agreement with table 9 in the CSW standard.

The csw:ElementName XPath support has also been upgraded in trunk (rev 8037) using the XPath processing methods from jeeves.utils.Xml with any namespaces used in the XPath loaded from a list built when parsing the metadata schema. This should make it more flexible in handling ISO profiles than the Java encoded XSLT in 2.6.4. eg. The following GetRecords query has a csw:ElementName that includes Marine Community Profile (MCP) namespaces:

<csw:GetRecords xmlns:csw="http://www.opengis.net/cat/csw/2.0.2&quot; xmlns:dc="http://purl.org/dc/elements/1.1/&quot; service="CSW" version="2.0.2" resultType="results_with_summary" startPosition="1" maxRecords="20" outputSchema="csw:IsoRecord">
   <csw:Query typeNames="csw:Record">
   <csw:ElementName>gmd:identificationInfo/mcp:MD_DataIdentification/gmd:extent/mcp:EX_Extent/mcp:taxonomicElement</csw:ElementName>
   <csw:Constraint version="1.0.0">
     <ogc:Filter xmlns:ogc="http://www.opengis.net/ogc&quot;&gt;
       <ogc:PropertyIsLike wildCard="%" singleChar="_" escape="\">
         <ogc:PropertyName>AnyText</ogc:PropertyName>
         <ogc:Literal>%Beekeeping%</ogc:Literal>
       </ogc:PropertyIsLike>
      </ogc:Filter>
   </csw:Constraint>
   </csw:Query>
</csw:GetRecords>

(Response is attached).

The same XPath approach is used for both csw:Record and csw:IsoRecord output schemas now so you should be able to use XPath syntax in either output.

Cheers and thanks for the detailed bug report/query!
Simon
________________________________________
From: Sylvain Grellet [s.grellet@anonymised.com]
Sent: Saturday, 23 July 2011 1:51 AM
To: Sylvain GRELLET
Cc: Pigot, Simon (CMAR, Hobart); Simon.Pigot@anonymised.com; geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] CSW / Xpath / ElementName issue on dc:date

Quick feedback after having deployed the 2.6.4.

- The xPath bug is not there anymore when using expressions like (cf
http://osgeo-org.1803224.n2.nabble.com/CSW-and-Xpath-on-ElementName-MD-Keywords-issue-td6603029.html)
:
<csw:ElementName>/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:descriptiveKeywords/gmd:MD_Keywords</csw:ElementName>
I retrieve all the necessary Keywords or CI_OnlineResource elements.

- But the issue with dc:date is still there :frowning:

Thanks Simon for having identified what was done under rev 7565.

Sylvain

Le 21/07/2011 15:11, Sylvain Grellet a écrit :

Ok great.

If you happen to find the issue behind the dc:date one as well, tell me.
Having xslt done on the client side would be lighter with dc: outputs
rather than full ISO 19139.

Thanks.

Sylvain

Le 21/07/2011 15:05, Simon.Pigot@anonymised.com a écrit :

Great! Thanks. From ticket 492 it looks like the Jeeves XPath class has other issues, so an alternative was required. I can see the change to an XSLT in 2.6.x (it's rev 7565) but not in trunk (which is what confused me). Now that the schema plugins are in the trunk, I wonder whether for trunk we could avoid coding the XSLT in Java and instead use the JAXP XPath class (through methods in jeeves.utils.Xml) preloaded with the namespaces from the appropriate metadata schema? As it happens I need this function to work in a CSW client so I'll take a look at that instead :-).

Cheers and thanks again,
Simon
________________________________________
From: Sylvain Grellet [s.grellet@anonymised.com]
Sent: Thursday, 21 July 2011 10:10 PM
To: Simon Pigot
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] CSW / Xpath / ElementName issue on dc:date

Hi Simon,

Thanks for your quick reply.
Concerning Jeeves, ticket 492
(http://trac.osgeo.org/geonetwork/ticket/492) mentions :
"A proposed fix for this is to replace the handling of ElementName
parameters to no longer use the Jeeves Xpath class, and instead generate
an XSLT on the fly that contains".
It's not the same issue than mine but at least, mentions a possible
common solution.

Apparently it's fixed and in 2.6.4.
Not sure if the fix applied is getting rid of Jeeves Xpath class or
something else.

Sylvain

Le 21/07/2011 12:47, Simon Pigot a écrit :

Hi Sylvain,

On 07/21/2011 07:56 PM, Sylvain Grellet wrote:

Hi,

Given the issue I mentioned in my other e-mail (see :
http://osgeo-org.1803224.n2.nabble.com/CSW-and-Xpath-on-ElementName-MD-Keywords-issue-td6603029.html)

This issue appears to be a limitation of the XPath code in Jeeves that
we are using - it only returns one element (the first one if there is
more than one) - it should be enhanced to return a list if there is
more than one element that matches the XPath. Not hard to do I think -
I'll take a look shortly if no one else is doing this already.

I tried to find a workaround using Dublin Core in our CSW web
development.

Looking at http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd, I
asked for the dc:date element in the request but
<csw:ElementName>dc:date</csw:ElementName>
does not work. Neither dc:creator, dc:description, dc:publisher,
dc:contributor (for creator/publisher/contributor I tested with metadata
having the expected values).

Whereas others from 'Table 9 - Mapping to common returnable properties'
(07-045 OpenGIS_Catalogue_Services Specification) seem to work

Any idea why ?

Not sure why the dc: ones you tried above didn't work. I'll take a
look when investigating the above (again, if no one else is doing that
already).

Compared to the other thread, what is weird it that here :
<csw:ElementName>dc:subject</csw:ElementName>
provides all the Keywords stored

Looking at the code, this is because XPaths are not used on
CSW-discovery responses - this metadata format is not nested so the
code simply removes all elements in the response record that don't
match the ones you specified as ElementNames - so that's why you get
all the keywords/dc:subject elements.

Cheers and thanks,
Simon

------------------------------------------------------------------------------
5 Ways to Improve& Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
_______________________________________________
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

------------------------------------------------------------------------------
5 Ways to Improve& Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
_______________________________________________
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