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

[Stefan Keller]

Hi Carl

I apologize of sometimes being rude especially about OGC spec. I
accept OGC's role in standardization. To me this means high
responsibility and therefore I'm having high expectations about the
quality of the process and the output.

2013/7/12 Carl Reed <creed at opengeospatial.org>:
> 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.

I did'nt find the presentation. Can you give me a link?

To backup my opinion that most OGC WxS aren't really fully RESTful I'd
like to point to the REST anti-patterns [1].
AFAIK most WxS including "WMTS using HTTP KVP encoding" (chap. 8) [2]
use anti-pattern 1 and 2 ("Tunneling everything through GET and
POST").
And WMTS is "overengineered" among others because it requires that "A
WMTS client SHOULD support both KVP and RESTful" (chap. 11.1).

Yours, Stefan

[1] http://www.infoq.com/articles/rest-anti-patterns
[2] http://www.opengeospatial.org/standards/wmts


http://www.infoq.com/articles/rest-anti-patterns


2013/7/12 Carl Reed <creed at opengeospatial.org>:
> 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