[OSGeo-Standards] Was: "file" formats. Is: GeoWeb

[Peter Baumann]

REST is nice: I can say
     Accept: image/jp2, image/png
like in http, and the server can pick. Works with my browser, with apache since 
last millennium. Thanks to IETF's http and IANA's MIME types.

But then, is REST accepting the complete RFC 2616 Clause 14 wisdom?
Looking into RESTful interfaces I find
     www.acme.com/path/file?f=bmp
called RESTful. Wasn't REST about putting things into the path, rather than the 
query part of a URL? And where is "bmp" standardized?

Also, I find that REST, due to the directory paradigm it hardcodes, is 
essentially good for hierarchical data. Last hype of that kind was XML - only 
good for strict hierarchies. Well ahead of REST in the hype cycle. "RESTful 
architecture" means "organize data hierarchically, regardless of whether it was 
graphs, sets, arrays, or unstructured text". So RESTful "architecture" seems 
Procrustes, while REST as protocol has nice features indeed.

Also, I note that all this discussion is bypassing a wealth of research results 
on scalability. I remain to see how REST helps speeding up a request for "what 
is the maximum temperature we will have over Greece in the next 2 weeks?". Or to 
express, for that matter.

Hm. Not sure what REST is, actually.

Sorry, thinking out loud.

-Peter



On 07/09/2013 09:14 PM, Rushforth, Peter wrote:
> Hi,
>
> tl;dr ... apologies!  I'm keeping this to the standards list out of respect for people's in-baskets.
>
> I did not mean to instigate a discussion of file formats.  I have my favourite formats too!  And, I don't want to lecture expert technologists on technology, so I apologize if I seem to be doing that...
>
> Fifteen years ago or so, I thought "Web" Map Service was going to be "it".  It was how I understood you put maps and the Web together. But, it turns out, there's not enough Web in that or any other geo service I know of.  The Web has gone on to scale up exponentially in the interim, leaving behind those parochial services we thought were "Web".  Yet we have kept on repeating the same pattern.  More of the same is not going to help.
>
> REST built the Web, and the GeoWeb needs REST in order to be built.  Without REST, there will be no 'Web' in Geo.
>
> The reader's digest nature of REST, as originally specified, and why it is important for geographic services:
> Hypermedia As The Engine Of Application State is the key constraint identified by Fielding which constitutes REST.  Everything else is just not REST.
>
> The idea behind that constraint is that the specification of a format which contains links (hypermedia), can be 'easier' to standardize than interfaces.   The format can then be served by many servers, and consumed by many clients.  The contract is not between the client and the server.  There are two contracts, one between the client and the format and another between the server and the format.  The result is the de-coupling of client and server.  If I change my web site, you can still read it, iff I respect the contract between the server and the format (html).
>
> In order to 'be RESTful', a client application reads the "file" (really the entire response, including headers) which is transferred to it over HTTP, and, discovering links therein, either follows them, thereby replacing/changing its state, or loads the resource, augmenting/changing its current state.
>
> To try to shorten a long story...
>
> Currently the only RESTful system which matters is the html Web.
>
> It is my personal professional belief that the only practical way to build a GeoWeb is to add map (client) semantics to directly into html, and thereby build it (html) into the GeoWeb. To be clear:  add a "geomap" tag to html. Browsers already have a contract with html.  In order to create a GeoWeb, we need to change html and concommitantly, browsers, to a new version of that contract.   We need to specify a browser-provided (js) API for maps around a "geomap" tag.
>
> The interface is http.  Browsers are not going to implement your interface.  The only interface they're going to implement is GET.  Browsers are not going to guess / build URI from component hierarchies.  They want links, preferably fully formed.
>
> The service format consumed by the html map client: the only practical way to do this is with hypertext.  The service format(s) must start with hypertext.  I suggest Atom, because it is a  widespread (community) standard hypertext base, having (appropriate) collection/member semantics.  GeoRSS(Atom)-GML would be an excellent extensible starting point for a geo service format.    It is already gaining traction in the OGC.  I am not a tiling expert, but my instinct tells me that tilesets/tiles would have good collection/member semantics.  What would be needed would be suitable hypermedia constructs for map navigation: link relations (e.g. "east", "west", (c.f. Allan Doyle geo-web-rest)..., "zoomin", "zoomout" etc). Possibly URI templates (they are hypertext too, if the client reads them).
>
> Regarding the contract between servers and format. Web servers already serve arbitrary html.  So that is no problem.  But for Web scale, I suggest an actual "mod_geomap" for apache, which could serve the contents of a tiled filesystem as feeds.  The feed format is the contract for both the server *and* the html client.  That's not to say there could not be a plethora of servers.  There could be, just as there are tomcats, jettys, etc. there will be geoservers, mapservers, arcgis servers, whatever.  Respect the contract and you get to play!
>
> That's my view of the needs for (+/- open source) geo software and open standards.
>
> Regards, and thanks for any feedback,
> Peter Rushforth
>
> N.B. I made a presentation on this topic to the OGC Mass Market DWG in Dec 2009, but the artifacts seem to be read-protected.  If anyone is interested let me know.
> P.S. If you reply I may not (be able to) respond until tomorrow.
>
>
> _______________________________________________
> Standards mailing list
> Standards at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/standards

-- 
Dr. Peter Baumann
  - Professor of Computer Science, Jacobs University Bremen
    www.faculty.jacobs-university.de/pbaumann
    mail: p.baumann at jacobs-university.de
    tel: +49-421-200-3178, fax: +49-421-200-493178
  - Executive Director, rasdaman GmbH Bremen (HRB 26793)
    www.rasdaman.com, mail: baumann at rasdaman.com
    tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis 
dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec 
preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)