[OSGeo-Standards] OWS Context and others OGC interactions

Tue Oct 23 09:08:53 EDT 2007

Hi,

Jody is correct.  OWS Context allows for an Extension element.

Currently, in OWS Context 0.2.0
(http://www.ogcnetwork.net/schemas/owc/0.2.0/owsContext.xsd), extensions
are allowed wihtin the General element, and _within_ the
AbstractResourceType, where AbstractResourceType is
Layer|Coverage|FeatureType.

It has been discussed to allow extension at the ResourceList level, to
allow for Layer|Coverage|FeatureType|whatever, but there have been
concerns of hindering interoperability.  At the same time, if folks are
going to do this anyway...

Having said this, if folks think this is useful, we could look at
examples of how to use Extensions at the AbstractResourceType level.

Standards are useful :)

..Tom

> -----Original Message-----
> From: standards-bounces at lists.osgeo.org 
> [mailto:standards-bounces at lists.osgeo.org] On Behalf Of Jody Garnett
> Sent: 22 October, 2007 7:02 PM
> To: Lorenzo Becchi
> Cc: standards at lists.osgeo.org
> Subject: Re: [OSGeo-Standards] OWS Context and others OGC interactions
> 
> Hi Lorenzo; just want to make sure I understand the goal here 
> ... if I understand the goal here is how to add more stuff 
> (specifically support for additional protocols) to these documents?
> 
> One thing I liked about a lot of the OGC specs is their 
> respect for "vendor specific extentions"; the idea is to 
> create a schema with a well known place for people to dump in 
> additional content; after a while (if the need is common 
> enough) you can promote the solution to a first class element 
> in your schema.
> 
> You list a couple of options:
> - mess with additional mime types (credit Jeroen ); am I to 
> assume that these would be mime types for the <Layer> element?
> - create more types of content
> 
> It would be more in the spirit of the document to create 
> additional kinds of contents; for some types of content (A 
> google layer) enough web applications have the need that you 
> can probably bang up something now. 
> The advantage is you do not have to worry about tripping over 
> the "rest" 
> of the WMS specific stuff like named style that would 
> otherwise conflict with a google satellite backdrop.
> > <Extension queryable="0" hidden="0" group="Layers">
> >    <ows:Title>Background</ows:Title>
> >    ....
> >    <Server service="google" version="2.0" title="Google Maps">
> >        <OnlineResource xlink:type="simple" 
> > xlink:href="http://maps.google.com/api/"/>
> >     </Server>
> >    <sld:MinScaleDenominator>5000</sld:MinScaleDenominator>
> >    <sld:MaxScaleDenominator>50000</sld:MaxScaleDenominator>
> >    <StyleList>
> >     <Style current="1">
> >        <Name>default</Name>
> >        <Title>satellite</Title>
> >       </Style>
> >    </StyleList>
> > </Extension>
> The advantage of the version is to let applications know what 
> version of the API the context document was prepared against; 
> etc... For us poor desktop applications we can try stubbing 
> in appropriate content if we can recognize what content is 
> being served up.
> 
> Cheers,
> Jody
> 
> 
> Lorenzo Becchi wrote:
> > 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.
> And when you want to communicate between a couple of 
> applications we will at least need a a small S "standard" 
> (wiki page fine). We can leave a captial "S" Standard up to 
> people in the past ;-)
> > 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</UR
> > I>
> >
> > 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
> >
> >
> > _______________________________________________
> > Standards mailing list
> > Standards at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/standards
> 
> _______________________________________________
> Standards mailing list
> Standards at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/standards
> 