Hi, just to not cause confusion: this is about WFS DescribeFeatureType, not WMS GetCapabilities.
On Sat, Feb 14, 2009 at 2:03 AM, Andreas Hocevar <ahoce...@opengeo.org> wrote: > Hi, > > after a long break, I revisited this format class in Bart's sandbox, > rewrote it using the new XML parsing style for better performance, and > made the output more verbose and closer to the schema (e.g. we now use > targetNamespace instead of featureNS). The new version also supports > restricted types. > > Ticket with patch: http://trac.openlayers.org/ticket/1202 > > Regards, > Andreas. > > On Wed, Dec 10, 2008 at 8:20 AM, <bart...@osgis.nl> wrote: >> Hi Andreas, >> >> that makes sense, and was exactly what I was thinking as well this >> morning. Remove the versioned parser and have an unversioned parser. I'll >> make some changes today in the sandbox to reflect this. >> >> Best regards, >> Bart >> >>> bart...@osgis.nl wrote: >>>> if Mapserver is using the version attribute for the XMLSchema version, >>>> that's a mistake, see: >>>> >>>> http://lists.opengeospatial.org/pipermail/wfs-dev/2008-December/000523.html >>>> >>> >>> That's interesting. Interesting because this does not seem to be part of >>> the WFS spec, and because it is different than with other OGC services. >>> And if it is true, we will definitely put no further effort into version >>> detection and get rid of Format.WFSDescribeFeatureType.v1_0 in favor of >>> having just one unversioned parser. >>> >>> Does this make sense? >>> >>> Regards, >>> Andreas. >>> >>>>> Andreas Hocevar wrote: >>>>> >>>>>> bart...@osgis.nl wrote: >>>>>> >>>>>> >>>>>>> With 4) I don't really agree, since 0.1 is a very arbitrary used >>>>>>> version >>>>>>> by Mapserver. Since it is the version of the application schema, it >>>>>>> should >>>>>>> not be used at all IMHO. I think the person calling the parser is >>>>>>> responsible for putting the version in the constructor, since he also >>>>>>> knew >>>>>>> the version when doing the DescribeFeatureType request (version is a >>>>>>> URL >>>>>>> parameter there). I've used this approach in the test cases. What do >>>>>>> you >>>>>>> think? >>>>>>> >>>>>>> >>>>>>> >>>>>> Good point. You are right that this 0.1 version is arbitrary, because >>>>>> XML Schema is currently at version 1.1 or something. For now, I really >>>>>> think you are right that parsing the version attribute is an >>>>>> inappropriate way to determine what we have to parse here. So yes, >>>>>> omitting the version detection seems ok for now. If we find WFS >>>>>> implementations out there that return a completely different schema, >>>>>> we >>>>>> will have to cope with this in a different way. >>>>>> >>>>>> >>>>> Wait. The "0.1" that Mapserver returns for the version is indeed the >>>>> version of the XML Schema. So in fact we should have a >>>>> Format.Schema.v0_1 and Format.Schema.v1_0 parser and mix this in for >>>>> the >>>>> WFSDescribeFeatureType parser. >>>>> >>>>> At least that is how it should be done. For now, your proposal does >>>>> definitely make sense, at least until we find some other use case where >>>>> we need to parse XML Schema. This can easily be refactored later >>>>> without >>>>> changing the API. >>>>> >>>>> Regards, >>>>> Andreas. >>>>> >>>>> -- >>>>> Andreas Hocevar >>>>> OpenGeo - http://opengeo.org/ >>>>> Expert service straight from the developers. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Andreas Hocevar >>> OpenGeo - http://opengeo.org/ >>> Expert service straight from the developers. >>> >>> >> >> >> _______________________________________________ >> Dev mailing list >> Dev@openlayers.org >> http://openlayers.org/mailman/listinfo/dev >> > > > > -- > Andreas Hocevar > OpenGeo - http://opengeo.org/ > Expert service straight from the developers. > -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers. _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
