[OpenLayers-Dev] [OpenLayers-Users] WMS GetCapabilities parser

[Andreas Hocevar]

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.