xlink:href is different to other ClientProperty mappings because it is used to express an identity relationship. For a one-to-many relationship, it is expected that multivalued xlink:href ClientProperty mappings result in multiple properties (leaf nodes), each with an xlink:href attribute.
The app-schema plugin fails to encode multivalued xlink:href ClientProperty as expected, except in the case of feature chaining. The problem is that new leaf nodes are not constructed after the first of the multiple values, resulting in a single leaf node having the last value (each subsequent value overwrites the attribute on the leaf node). The workaround, using feature chaining, cannot be implemented for properties with an empty content model (i.e. reference-only types).
The fix is to automatically add a new leaf node when mapping values to a property that has maxOccurs > 1 (multiple values are allowed) and the existing leaf node of that instance already has an xlink:href.
Ben Caradoc-Davies
July 30, 2016 at 9:23 AM
Cherry-picked on to GeoTools 15.x and 14.x and GeoServer 2.9.x and GeoServer 2.8.x,
xlink:href is different to other ClientProperty mappings because it is used to express an identity relationship. For a one-to-many relationship, it is expected that multivalued xlink:href ClientProperty mappings result in multiple properties (leaf nodes), each with an xlink:href attribute.
The app-schema plugin fails to encode multivalued xlink:href ClientProperty as expected, except in the case of feature chaining. The problem is that new leaf nodes are not constructed after the first of the multiple values, resulting in a single leaf node having the last value (each subsequent value overwrites the attribute on the leaf node). The workaround, using feature chaining, cannot be implemented for properties with an empty content model (i.e. reference-only types).