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

[Stefan Keller]

Hi Peter

2013/7/12 Rushforth, Peter <Peter.Rushforth at nrcan-rncan.gc.ca>:
...
> I think XLink is a dead end for REST, actually.  Atom has Web-oriented linking
> semantics built in.
...

Your're right.
Atom Pub is the better choice one hand for the link element semantic
and on the other hand because it's a nice mime type.

Yours, Stefan


2013/7/12 Rushforth, Peter <Peter.Rushforth at nrcan-rncan.gc.ca>:
> 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