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

[Carl Reed]

Stefan -

Interesting comment "WMTS is not RESTful yet because of other reasons". 
There is a presentation on the OGC website that documents Why WMTS is 
RESTful. This presentation was provided as part of the approval process for 
WMTS.

This inability to agree on what a RESTful service is (or the interface) has 
plagued REST work in the OGC for years. This is why the OGC Architecture 
Board suggests a pragmatic approach - implement REST interfaces for several 
existing OGC standards (WFS, WPS, WCS etc) and find out what in practice 
(not in the abstract) a RESTful OGC web service is and then document the 
best practice and guidance for future work.

Also, GeoPackage defines rules for a container of geo-content (binary). 
These rules (requirements) define the internal format for storage on a 
device. The geometry elements are in line with OGC/ISO Simple Features and 
ISO 19107.

Cheers

Carl




-----Original Message----- 
From: Stefan Keller
Sent: Friday, July 12, 2013 3:27 AM
To: Rushforth, Peter
Cc: standards at lists.osgeo.org
Subject: Re: [OSGeo-Standards] Was: "file" formats. Is: GeoWeb

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
_______________________________________________
Standards mailing list
Standards at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/standards