[GeoNetwork-devel] WFS Harvester XSLT bug + Fix

Hi All,

My 2.4.2 / 2.4.3 geonetwork instance is failing to harvest the MD_Metadata/distributionInfo/MD_Distribution/ transferOptions/ MD_DigitalTransferOptions/onLine/CI_OnlineResource/linkage/URL from some of my WFS’s (all version 1.1.0).

I did a bit of digging and it looks like it’s because the root element of the ‘faulty’ WFS GetCapabilities response is defined with no prefix (See below).

<WFS_Capabilities xmlns=“http://www.opengis.net/wfs” version=“1.1.0” xsi:schemaLocation=“http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd”>

Whereas the WFS’s that are being harvested correctly all specify the root element as

<wfs:WFS_Capabilities xmlns:wfs=“http://www.opengis.net/wfs” version=“1.1.0” xsi:schemaLocation=“http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd”>

From what I can tell both are valid XML so I started to think it may be a bug with GN. Having a look at geonetwork/xsl/conversion/import/OGCWxSGetCapabilities-to-ISO19119_ISO19139.xsl there is a section that tests

test=“name(.)=‘wfs:WFS_Capabilities’ or name(.)=‘wps:Capabilities’”

Which is only testing the Prefix name, not the actual namespace URI that the prefix is representing. It should really read something like the following (I’m no XSLT expert so there may be a more succinct way of doing this…)

test=“local-name(.)=‘WFS_Capabilities’ and namespace-uri(.)=‘http://www.opengis.net/wfs’ or local-name(.)=‘Capabilities’ and namespace-uri(.)=‘http://www.opengeospatial.net/wps’”

I’ve attached a patch of this change, I haven’t searched for any other instances of this issue…

Josh Vote
Mineral Down Under Flagship | AuScope Grid
CSIRO Earth Science and Resource Engineering

Phone: +61 8 6436 8607
Josh.Vote@anonymised.com | www.csiro.au
Address: Australian Resources Research Centre, 26 Dick Perry Avenue, Kensington WA 6151

PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.

Please consider the environment before printing this email.

(attachments)

gn-xslt-fix.patch (799 Bytes)

I spoke too soon and found another instance, attached is an updated patch.

So these patches don’t get lost, where is the ‘correct’ place to sending them, I don’t believe I have commit permissions to GN trunk.

Thanks

Josh

From: Josh.Vote@anonymised.com [mailto:Josh.Vote@anonymised.com]
Sent: Monday, 30 August 2010 3:53 PM
To: geonetwork-devel@lists.sourceforge.net
Subject: [ExternalEmail] [GeoNetwork-devel] WFS Harvester XSLT bug + Fix

Hi All,

My 2.4.2 / 2.4.3 geonetwork instance is failing to harvest the MD_Metadata/distributionInfo/MD_Distribution/ transferOptions/ MD_DigitalTransferOptions/onLine/CI_OnlineResource/linkage/URL from some of my WFS’s (all version 1.1.0).

I did a bit of digging and it looks like it’s because the root element of the ‘faulty’ WFS GetCapabilities response is defined with no prefix (See below).

<WFS_Capabilities xmlns=“http://www.opengis.net/wfs” version=“1.1.0” xsi:schemaLocation=“http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd”>

Whereas the WFS’s that are being harvested correctly all specify the root element as

<wfs:WFS_Capabilities xmlns:wfs=“http://www.opengis.net/wfs” version=“1.1.0” xsi:schemaLocation=“http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd”>

From what I can tell both are valid XML so I started to think it may be a bug with GN. Having a look at geonetwork/xsl/conversion/import/OGCWxSGetCapabilities-to-ISO19119_ISO19139.xsl there is a section that tests

test=“name(.)=‘wfs:WFS_Capabilities’ or name(.)=‘wps:Capabilities’”

Which is only testing the Prefix name, not the actual namespace URI that the prefix is representing. It should really read something like the following (I’m no XSLT expert so there may be a more succinct way of doing this…)

test=“local-name(.)=‘WFS_Capabilities’ and namespace-uri(.)=‘http://www.opengis.net/wfs’ or local-name(.)=‘Capabilities’ and namespace-uri(.)=‘http://www.opengeospatial.net/wps’”

I’ve attached a patch of this change, I haven’t searched for any other instances of this issue…

Josh Vote
Mineral Down Under Flagship | AuScope Grid
CSIRO Earth Science and Resource Engineering

Phone: +61 8 6436 8607
Josh.Vote@anonymised.com | www.csiro.au
Address: Australian Resources Research Centre, 26 Dick Perry Avenue, Kensington WA 6151

PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.

Please consider the environment before printing this email.

(attachments)

gn-xslt-fix.patch (1.66 KB)

Hi Josh,

You could open a ticket on GeoNetwork opensource Developer website and attach your patch to the ticket? (You'll need to create yourself an OSGeo user account).

Cheers and thanks,
Simon
________________________________________
From: Josh.Vote@anonymised.com [Josh.Vote@anonymised.com]
Sent: Tuesday, 31 August 2010 1:43 PM
To: geonetwork-devel@lists.sourceforge.net
Subject: [ExternalEmail] Re: [GeoNetwork-devel] WFS Harvester XSLT bug + Fix

I spoke too soon and found another instance, attached is an updated patch.

So these patches don’t get lost, where is the ‘correct’ place to sending them, I don’t believe I have commit permissions to GN trunk.

Thanks
Josh

From: Josh.Vote@anonymised.com [mailto:Josh.Vote@anonymised.com]
Sent: Monday, 30 August 2010 3:53 PM
To: geonetwork-devel@lists.sourceforge.net
Subject: [ExternalEmail] [GeoNetwork-devel] WFS Harvester XSLT bug + Fix

Hi All,

My 2.4.2 / 2.4.3 geonetwork instance is failing to harvest the MD_Metadata/distributionInfo/MD_Distribution/ transferOptions/ MD_DigitalTransferOptions/onLine/CI_OnlineResource/linkage/URL from some of my WFS’s (all version 1.1.0).

I did a bit of digging and it looks like it’s because the root element of the ‘faulty’ WFS GetCapabilities response is defined with no prefix (See below).

<WFS_Capabilities xmlns="http://www.opengis.net/wfs&quot; version="1.1.0" xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd&quot;&gt;
...

Whereas the WFS’s that are being harvested correctly all specify the root element as

<wfs:WFS_Capabilities xmlns:wfs="http://www.opengis.net/wfs&quot; version="1.1.0" xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd&quot;&gt;
...

From what I can tell both are valid XML so I started to think it may be a bug with GN. Having a look at geonetwork/xsl/conversion/import/OGCWxSGetCapabilities-to-ISO19119_ISO19139.xsl there is a section that tests

test="name(.)='wfs:WFS_Capabilities' or name(.)='wps:Capabilities'"

Which is only testing the Prefix name, not the actual namespace URI that the prefix is representing. It should really read something like the following (I’m no XSLT expert so there may be a more succinct way of doing this...)

test="local-name(.)='WFS_Capabilities' and namespace-uri(.)='http://www.opengis.net/wfs’ or local-name(.)='Capabilities' and namespace-uri(.)='http://www.opengeospatial.net/wps’"

I’ve attached a patch of this change, I haven’t searched for any other instances of this issue...

Josh Vote
Mineral Down Under Flagship | AuScope Grid
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8607
Josh.Vote@anonymised.com | www.csiro.au<http://www.csiro.au/&gt;
Address: Australian Resources Research Centre, 26 Dick Perry Avenue, Kensington WA 6151
PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
Please consider the environment before printing this email.