[mapguide-users] WFS and the King Oracle FDO provider

[Jackie Ng]

Just an update on this.

I'm not going to make the planned fix of scrubbing out '~' characters in the
WFS response as this will most likely break how WFS clients are meant to
work:

 1. Request a WFS capabilities document
 2. Pick a WFS [encoded layer name]
 3. GetFeatures with the WFS [encoded layer name]
 4. Process the GetFeatures response using the [encoded layer name] to
determine how to extract the feature data whose elements will be named
[encoded layer name]

The fix I had would've addressed step 4, but would break steps 1-3 as WFS
would've still advertised the layer name with '~' and you would've still
needed the layer name with '~' to make the GetFeatures request, and if we
scrubbed the element name as per my planned fix it would break client
behaviour on how to handle step 4.

Scrubbing the '~' in the GetCapabilities response in step 1 is not an option
either, because at some point, we have to reverse translate that scrubbed
layer name back to the FDO class name, so that the FDO queries will still
work and there is no MapGuide-level configuration point currently that
allows us to define such class name mappings so we can forward and reverse
translate between FDO class names and WFS encoded layer names. This is
primarily something FDO providers provide (excuse the pun) through the
configuration document mechanism, or in the case of the King.Oracle
provider, the KingFdoClass special table.

So long story short, '~' was a *very poor* choice of delimiting character
used by the King.Oracle FDO provider that we currently can't workaround at
the MapGuide-level. Use the KingFdoClass mechanism to provide "clean" class
names that won't break WFS responses.

- Jackie



--
View this message in context: http://osgeo-org.1560.x6.nabble.com/WFS-and-the-King-Oracle-FDO-provider-tp5256626p5264530.html
Sent from the MapGuide Users mailing list archive at Nabble.com.