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

[Andreas Hocevar]

Bart,

#1202 is now committed to trunk. Thanks for your efforts and the good
discussion on this.

Please feel free to reopen if you feel that something is missing.

Regards,
Andreas.

On Sat, Feb 14, 2009 at 2:20 PM, Andreas Hocevar <ahocevar at opengeo.org> wrote:
> 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.
>



-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.