CSW / ElementName

[heikki]

This CSW query does not work in trunk (was working in 2.6 series):

<?xml version="1.0"?> <csw:GetRecords xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" service="CSW" version="2.0.2" resultType="results" maxRecords="100" outputSchema="csw:IsoRecord">

<csw:Query typeNames="gmd:MD_Metadata">

<csw:ElementName>/gmd:MD_Metadata/gmd:fileIdentifier</csw:ElementName>

<csw:ElementName>/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:identifier/gmd:RS_Identifier/gmd:code</csw:ElementName>

<csw:ElementName>/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:title</csw:ElementName> <csw:ElementName>/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:date/gmd:CI_Date/gmd:dateType/gmd:CI_DateTypeCode/@codeListValue="publication"</csw:ElementName> <csw:ElementName>/gmd:MD_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:transferOptions/gmd:MD_DigitalTransferOptions</csw:ElementName>

</csw:Query>

</csw:GetRecords>

Discussed with FXP and the spec (OGC 07-006) is inconsistent with the ISO19139 XSD, and otherwise incomplete. According to the XSD, ElementName is a QName, so cannot be an XPATH; but according to OGC 07-006 it must be XPATH.. Also the spec is not clear about what to do with typeNames in all situations.

Agreed with FXP that we

• allow for XPATH in ElementName (even if this violates the XSD)

• handle typeNames as follows :

a) if ElementName starts with "/", do a XPATH against the root of the document -- typeNames is ignored in this case

b) if not, and there is one typeName, do a XPATH against the typeName, ie typeName/elementName

c) if not, and there are more than one typeName, do a XPATH against the typeNames, ie typeName1/elementName

typeName2/elementName

[heikki]

Several issues with not complying to the specs in GetRecords. Fixing some of those, but for now here is at least a quick fix that makes above request work again.

Trunk rev. 8638

[heikki]

Changes to GetRecords dealing with ElementNames and typeName :

• support required typeName. Value can be either csw:Record or gmd:MD_Metadata (in accordance with OGC 07-045 8.2.2.1.1).

• according to specs, typeName is used to (a) restrict the possible queryables: this is not implemented; and (b) resolve the XPATH in elementnames: this is now implemented such that:

case 1: elementname start with / : use it as the xpath as is (ignoring typeName);

case 2: elementname does not start with / :

case 2a: elementname starts with one of the supported typeNames (csw:Record or gmd:MD_Metadata) : prepend /

case 2b: elementname does not start with one of the supported typeNames : prepend with /typeName

in accordance with OGC 07-006 10.8.4.11.5 (but it's only applied to ElementName)

• GeoNetwork should only return valid metadata in GetRecords responses, because we only accept outputFormat 'application/xml' (according to OGC 07-006 10.8.4.4). The previous practice of returning only the requested ElementName, stripped from the rest of the metadata, did not return valid metadata. However to accommodate backwards-compatibility, an optional GN-specific attribute "elementnameStrategy" to Query elements is introduced:

For ElementNames, several strategies are implemented. Clients can determine the behaviour by sending attribute "elementnameStrategy" with one of the following values:

• csw202
• relaxed
• context
• geonetwork26

The default is 'relaxed'. The strategies cause the following behaviour:

• csw202 -- compliant to the CSW2.0.2 specification. In particular this means that complete metadata are returned that match the requested ElementNames, only if they are valid for their XSD. This is because GeoNetwork only supports OutputFormat=application/xml, which mandates that valid documents are returned. Because possibly not many of the catalog's metadata are valid, this is not the default.

• relaxed -- like csw202, but dropped the requirement to only include valid metadata. So this returns complete metadata that match the requested ElementNames. This is the default strategy.

• context -- does not return complete metadata but only the elements matching the request, in their context (i.e. all ancestor elements up to the root of the document are retained). This strategy is similar to geonetwork26 but the context allows clients to determine which of the elements returned corresponds to which of the elements requested (in case they have the same name).

• geonetwork26 -- behaviour as in GeoNetwork 2.6. Just return the requested elements, stripped of any context. This can make it impossible for the client to determine which of the elements returned corresponds to which of the elements requested; for example if the client asks for gmd:title, the response may contain various gmd:title elements taken from different locations in the metadata document.

Rev. 8651 (also includes #491).