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

[Stefan Keller]

Hi Peter

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

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.

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?
To me that's where "WSDL for REST" comes in.

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.

For vector features and feature collections we already have xlink and
grouping - to there's nothing to do here for a contract I think. To me
the elephant in the room is which format: Interestingly neither
GeoJSON nor GeoPackage have been mentioned yet!?

Yours, Stefan


2013/7/11 Rushforth, Peter <Peter.Rushforth at nrcan-rncan.gc.ca>:
> Arnulf,
>
>> Which is why the underlying architecture paradigm is called resource orientation.
>
> Resource and representation is part of REST, yes.  Let's try to be a bit clear about terminology.  At least REST has a definition.
>
>> If we take some raster data to be the resource
> I would say that's not a great starting point for a resource data model.  Maybe "the earth", or some part thereof would be a more concrete concept?
>
>> then any part and information derived from this data is a representation of this resource.
>
> Yes, that's one aspect of the resource-representation duality: the server is free to serve up a partial representation of the whole resource, not only different formats, languages etc. The partial nature of the representation is mitigated by the ability to include links to other parts in hypertext.
>
>> It is perfectly fine for a representation (for example a file) to not
>> have any hypertext component or link embedded in them (think PNG image).
>> It can still be part of a REST environment. The raster representation
>> that is returned for a GET request could well be wrapped into some
>> hypertext, this would make things even nicer but is not required at all
>> times.
>
> I'm not sure what you mean by "at all times".  That statement is taken by most
> "REST APIs" to mean "never", or "only incidentally, but not required by this spec"
> from what I've seen.
>
> We should be starting the other way around, IMHO where we're defining the hypermedia
> context for services, and let implementers work out their own rules for the URI
> for this image or that coverage.  Note that hypermedia can be quite sophisticated,
> with standards-based URI Templates [1]
>
> Cheers,
> Peter
>
> [1] http://tools.ietf.org/html/rfc6570
> _______________________________________________
> Standards mailing list
> Standards at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/standards