I want to add that there is support to do some transformation of the underlying data store before output so you can conform to something other than the default GML model. Here is a link to a tutorial we developed as part of an FGDC grant that might help:
http://maps.dnr.state.mn.us/mapserver_docs/wfs_tutorial/index.html In addition, besides transforming the data you also need to produce a transformed schema, the tutorial covers both. We played with having the WFS describeFeatureType response import an external schema rather than generating it. I can dig out that configuration option if you'd like. In that case you configure MapServer to output XML that matches an external schema and reference the remote schema document (so a describeFeatureType response becomes very simple, just a bunch of imports. I can't remember if that was perfected though and have meant to get back to it. One caveat is that with WFS you need to be able to support filters against what you transform and we don't do that yet. It's possible to invert the transformations noted in the above tutorial but it hasn't been completed. Using XSLT suffers from the same problem. Steve >>> On 6/4/2007 at 1:32 PM, in message <[EMAIL PROTECTED]>, "Kralidis,Tom [Burlington]" <[EMAIL PROTECTED]> wrote: >> I would like to know if it's possible to have a WFS-G or >> another WFS-XX with a xml schema different than default GML model. > > With out-of-the-box MapServer, basically your underlying data structure > is displayed as a pre-defined XML content model. > > One option you can checkout is using mapscript as a wrapper for WxS > services (see http://mapserver.gis.umn.edu/docs/howto/wxs_mapscript), > where you can put logic in between the request and reponse model of OGC > services in MapServer. > > In this case, you could do an XSLT transformation on the generic-ish > MapServer WFS response to make it look like WFS-G, then sending back to > the client. > > Hope this helps > > ..Tom
