Ben Caradoc-Davies created GEOT-4105:
----------------------------------------
Summary: app-schema GML 3.2 gml:id xlink:href for repeated
elements in wrong location
Key: GEOT-4105
URL: https://jira.codehaus.org/browse/GEOT-4105
Project: GeoTools
Issue Type: Bug
Components: app-schema plugin, xsd-gml
Affects Versions: 8.0-RC1
Reporter: Ben Caradoc-Davies
Assignee: Rini Angreani
[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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
