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

[bartvde at osgis.nl]

Hi Andreas,

just to clarify, the 0.1 is not the version of XML Schema (which now is at
1.1 indeed), it's the version of the GML application schema used by the
WFS service. With Mapserver and Geoserver this always auto-generated, but
there are WFS products out there which can use a static xsd file, and if
the datamodel is updated, a new xsd is generated with preferably a higher
version.

Best regards,
Bart

> 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.
>
>