[OSGeo-Standards] OWS Context and others OGC interactions

[Lorenzo Becchi]

Hi All,
first of all I should apologize for my poor knowledge of OGC standards.
To be honest, I'm not sure that what I'm writing make totally sense. But hope it does.


In a recent debate bewteen OpenLayers (OL) and GeoNetwork (GN) communities we have tried to face a practical scenario using OGC standards.

Playing with OL and GN, I've decided to create a CSW search interface for OL to retrieve WMS or other kind of layers from a GN Catalogue.
That's all Javascript from OL client side while it's all XML what I'm expecting from GN Catalogue (JSON output would be a dream).
So I can receive a list of layers, with different flavored XML, and even a OWS Context.

I've never seen the OWS Context draft before Cameron Shorter's post sent yesterday...
now I'm surprised to see "FeatureType" or "Coverage" inside the ResourceList, but it seems a good way to offer a better service.

A possible problem of OGC standards is that they relate normally to OGC standards. That's ok to me, I'm getting older.  But think about 
what Chris Schmidt (OL Core Developer) always says about standards: "I don't need standards". That's because he's always a step forward in the future.

Jeroen Ticheler's idea, he's GN director,  was to include mime-types in the type definition of a layer or its server,
ex:
<URI mimetype="application/vnd.ogc.wms" title="National boundaries of Africa" name="national_boundaries_africa">http://geonetwork3.fao.org/ows/1</URI>

let's try to be creative:
<URI mimetype="application/google.satellite" title="Google Satellite Images from Google Maps" name="satellite">http://maps.google.com/api/</URI>

some more creativity:
<URI mimetype="application/osm.streets" title="Open Street Maps - Streets" name="street">http://www.osm.org/api/5.0/</URI>


we could use this solution instead of FeatureType and Coverage or joint with them.
Adopting mime type, the client application will be able to decide to use or not a kind of service (layer) if it has an interface to support 
it. Otherwise it will be able to throw it away or return an exception.
Every client will be free to support standards layers but add as many new features as Chris Schmidt can invent in one month (means many).
Ex: OpenLayers and Mapbuilder can easily support GoogleMaps today, why we should avoid uDIG to support it tomorrow? Maybe Google has a clear 
answer about it... Anyway, same thing about OSM but OSM has already a public API; why should we not make it an OGC indexable resource?


ciao
Lorenzo