app-schema GML 3.2 gml:id xlink:href for repeated elements in wrong location

[Originally reported on CSIRO Jira on 30/Jun/11. See: https://jira.csiro.au/browse/SISS-1086 (login required)]

Original report from Alistair Ritchie:

When an element with the same gml:id is repeated in an XML document all subsequent instances must be replaced with an xlink:href on the property in question hash referencing the initial occurrence.

For example, where two MappedFeatures have the same specification values, they should appear as:

<gsml30:MappedFeature gml:id="gsml.mappedfeature.contact.tb-250k-40000006">
[MappedFeature stuff]
<gsml30:specification>
<gsml30:Contact gml:id="gsml.contact.tb-0111">
[Contact stuff]
</gsml:30:Contact>
</gsml30:specification>
</gsml30:MappedFeature>

then

<gsml30:MappedFeature gml:id="gsml.mappedfeature.contact.tb-250k-40000055">
[MappedFeature stuff]
<gsml30:specification xlink:href="#gsml.contact.tb-0111"/>
</gsml30:MappedFeature>

Geoserver is wrongly encoding the second occurrence, resulting in schema invalid responses:

<gsml30:MappedFeature gml:id="gsml.mappedfeature.contact.tb-250k-40000006">
[MappedFeature stuff]
<gsml30:specification>
<gsml30:Contact xlink:href="#gsml.contact.tb-0111"/>
</gsml30:specification>
</gsml30:MappedFeature>

This has been observed in a number of contexts, not just gsml30:specification.

And later after much discussion and many delays:

-------- Original Message --------
Subject: Re: Geoserver and gml:ids (ii)
Date: Tue, 7 Feb 2012 11:29:36 +0800
From: Alistair Ritchie
To: Caradoc-Davies, Ben (CESRE, Kensington)
CC: Angreani, Rini (CESRE, Kensington), Fraser, Ryan (CESRE, Kensington)

OK, thanks for the update.

This may well cause grumbles in in the GeoSciML community as it renders MappedFeature responses invalid/useless.

Important point - unlike ERML services, GeoSciML GeologicFeatures almost always have multiple associated MappedFeatures, so an ability to properly 'escape' repeated GeologicFeatures inline in a MappedFeature is crucial to getting a valid response.

As a result, app-schema still can't be considered production ready and I can't recommend that the Geoserver work I've done for the sample DB 'goes live' until this is resolved. As far as deployment for GeoSciML goes, I'd be calling this a blocker.

I understand, however, that your local needs are driven by EarthResourceML, not GeoSciML, so there are competing requirements.

You'll be able to test using the reference database and Geoserver configurations - these will be published within a week.

Cheers,
Alistair

"XML is like violence. If it doesn't solve the problem, use more." - Unknown

On 7 February 2012 16:03, Ben Caradoc-Davies wrote:
I spoke too soon. This issue has just been deprioritised and kicked out of the 2012-02 iteration. I will pencil it in for 2012-03 in hope that we can have a look at it.

Kind regards,
Ben.