[OpenLayers-Dev] Format and version

[bartvde at osgis.nl]

Hi Chris,

in OWSContext the structure looks something like (top one is GML and
bottom one KML):

<Layer name="xxx">
  <Server service="urn:ogc:serviceType:GML" version="2.1.2" title="yyy">
    <OnlineResource xlink:href="http://www.my.org/LandUse.gml"/>
  </Server>
</Layer>
<Layer name="zzz">
  <Server service="urn:ogc:serviceType:KML" version="2.2" title="faketitle">
    <OnlineResource xlink:href="http://example.com/fakekml.kml"/>
  </Server>
</Layer>

The type of "service" I can determine from layer.protocol.format (at least
with the new OL structure), so I thought the version would make sense on
the format as well.

If a KML 2.2 file was read, Format.KML could store 2.2 as the version
property. If a KML 2.1 was read, the version property of the format could
state 2.1. In other words, it's okay (wanted) that the version changes
with the type of data read as you state below.

Best regards,
Bart

> On Fri, May 08, 2009 at 10:43:24AM +0200, bartvde at osgis.nl wrote:
>> Hi list,
>>
>> currently some of OL's Format classes have an uppercase VERSION
>> attribute/constant (Filter for instance) which contains the version of
>> the
>> Format, others have a lowercase version, and then again others have no
>> version info at all (like KML).
>>
>> When writing out a Layer's Server tag in OWSContext version is required.
>>
>> Is there any chance we could standardize this on OL's Format class?
>>
>> Thoughts?
>
> You said "when writing out a Layer's Server tag". To me, that implies
> that the version would be best attached to the layer, no? Finding it on
> the format seems strange.
>
> KML, for example, will read most versions of the KML format -- though
> none of them completely -- and therefore, every time you read data,
> you're going to get a different answer for the version...
>
> Seems like this is the kind of thing that you need to give the
> information on at the Layer level in order for it to be meaningful,
> at least in some cases.
>
> Regards,
> --
> Christopher Schmidt
> MetaCarta
>