[OpenLayers-Dev] WFS DescribeFeatureType (was: WMS GetCapabilities parser)

Andreas Hocevar ahocevar at opengeo.org
Sat Feb 14 08:20:20 EST 2009


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 <ahocevar at 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,  <bartvde at 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
>>
>>> bartvde at 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:
>>>>>
>>>>>> bartvde at 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 at 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.



More information about the Dev mailing list