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

[Andreas Hocevar]

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.

Regards,
Andreas.

> Best regards,
> Bart
>
>   
>> Hey Bart-
>>
>>
>> Eijnden, Bart van den (DID) wrote:
>>     
>>> 1) a response can have multiple typeNames, so now I've changed the
>>> output for attributes to have a multi-dimensional array i.e.
>>> attributes[layer][attribute].name. Is this okay with you guys since this
>>> changes your interface?
>>>
>>>       
>> The problem I see with your change that the new structure does not know
>> the typeName. So you would either have to make attributes a hash keyed
>> by typeName, or stick with attributes as it was and add a typeName
>> property to each attribute.
>>
>> I think the latter is easier to handle in most use cases, but I have no
>> strong preference.
>>
>>     
>>> 2) for type should we remove the namespace or not? Now we can have
>>> xsd:string, xs:string and string e.g.
>>>
>>>       
>> Since what we are parsing here is an XML Schema, we could in principle
>> also have complex types that are defined in the schema. So I would say
>> the type should be without namespace prefix, but there should be an
>> additional property called typeNS or something, containing the namespace
>> URI of the type.
>>
>>     
>>> 3) should we not also parse minOcccurs and nillable attributes? A WFS
>>> client needs to know this in order to know if the element can be
>>> ommitted or not. But maybe this quite specific and only used by Ionic
>>> and we should leave this for a future version?
>>>
>>>       
>> I think this is useful information and can be added without much effort.
>>
>>     
>>> 4) I've removed using the version of the root node, since this is not
>>> the WFS version but the application schema's version, see:
>>> http://lists.opengeospatial.org/pipermail/wfs-dev/2008-December/000521.html
>>>
>>>       
>> Good catch. GeoServer does not return a version at all, so the best
>> thing to do would be to set defaultVersion to "0.1" and rename the
>> versioned parser v1_0.js to v0_1.js.
>>
>>     
>>> Btw, feel free to edit the bartvde/owsformats sandbox. I hope we can
>>> quickly put this into a patch for OL trunk
>>>
>>>       
>> I'd say let's also hear Tim's opinion (and others can chime in as well
>> if they feel like), but from what I see making these final changes is an
>> effort of 1/2 hour for each of us if we share the work. I'd like to take
>> on the type namespace part.
>>     
>>> http://trac.openlayers.org/browser/sandbox/bartvde/owsformats
>>>
>>>       
>> Thanks for your efforts!
>> Andreas.
>>
>> --
>> 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.