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

[Rushforth, Peter]

Hi Stefan,

> Thanks for the discussion. 

Thanks for joining in!

> I think the book "REST in 
> Practice" fits your thoughts and can be recommended for all 
> as a basic lecture:
> http://restinpractice.com/book/

It's a good book, yes.  They lost me on the semantic stuff, but
I really liked their treatment of Atom.

> 
> As you say what's crucial to GeoWeb - and rather 
> understimated in REST discussion until now - is the contract. 
> That's why I like the above mentioned book. Producing a 
> broadly accepted contract - accepted not only among us but 
> even by browser manufacturers - makes it so difficult.

The part of the contract I'm referring to for the GeoWeb is the media type [1].  

> 
> You say there should be a contract against a server and a 
> format, and a format and a client. That's interesting, But 
> when separating the server-client-contract don't you loose 
> something like state change protocol metadata (and 
> negotiation) which you also have in a contract?

Yes I suppose you do.  So the protocol must be part of the contract.  
For the purposes of discussion of the Web, http is the protocol,
so I guess you could consider that the boilerplate part of the contract,
and potentially of limited use to discuss with OGC, since it is
already a well-established internet standard.  No need to re-specify it.

> To me that's where "WSDL for REST" comes in.

Aha!  There is a long and deep discussion for this, I think.  I generally
agree that possible state changes must be communicated to the client
from the server.   From what I understand, WSDL for REST, or WADL, or some
current popular json-based APIs use this architecture.  To me
GetCapabilities responses are pretty close to this.  There is nothing
intrinsically wrong with this architecture.  It is not Web architecture
though. 

State change metadata are not parsed out to the client throughout the
interaction as appropriate and needed.  Instead, all possible states are 
communicated "at once", and the client proceeds on that basis.  Often
clients can be code-generated for this approach.  Change the WSDL, the client
breaks because the contract it was generated for no longer exists, it
was "torn up".

In contrast, in the hypertext or hypermedia approach, each response from
the server carries metadata about possible state changes in the protocol
being used.  These may come in the form of fully formed links to
resources or resource parts, or, they may come in the form of
templated request headers, where variables representing protocol elements
(headers, or parts of headers) and their possible values are communicated in the
body of the response in a manner consistent with the syntax and semantics
of the media type [1].  Hence the important part of the REST contract
for our purposes is the media type.

> 
> Web map raster tiles already come close to a format since its 
> JPG, PNG etc. (and WMTS is not RESTful yet because of other 
> reasons). Perhaps the grouping information could go into the 
> protocol metadata? For raster to me there's no need for links 
> - except the spatial relationship which already is powerful.

I agree WMTS is not yet RESTful, but with a little effort could be made so.
I strongly think RESTful and useful must go together, however. 

> 
> For vector features and feature collections we already have 
> xlink and grouping - to there's nothing to do here for a 
> contract I think. 

I think XLink is a dead end for REST, actually.  Atom has Web-oriented linking
semantics built in.   Not that vector features (perhaps KML?)etc couldn't
adopt those semantics, but perhaps it's not necessary to open that
box because Atom already exists. 

> To me the elephant in the room is which 
> format: Interestingly neither GeoJSON nor GeoPackage have 
> been mentioned yet!?

I don't know.  Do either have link semantics built in?  My goal in creating
the thread title was to discuss architecture more than formats, because we
quickly forget the forest for the trees, so to speak when talking about 
geo formats.

Regards,
Peter

[1] http://tools.ietf.org/html/rfc2046