- From: Peter Rushforth via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Aug 2018 13:46:46 +0000
- To: public-sdwig@w3.org
@larsgsvensson and @dvh Interesting. I don't think headers will work for MapML, because the "tiled coordinate reference system" concept, and the definition of 'WGS84' are defined only within MapML as "projection" [values](https://maps4html.github.io/MapML/spec/#semantics). MapML aims to be a defined internet media type (text/mapml), so the definition of the media type would make it self-describing, as I understand that concept. A profile would seem to be an extension of a media type, if I understand the concept correctly. Perhaps when the definition of TCRS is widely enough accepted these could be considered profiles and header-based negotiation could also work. As a first pass, and without implying deeper protocol inspection than I wanted to get into at this time, having the media type provide a facility to adapt to the runtime environment seemed like a win. Early on I did try negotiating the projection off a media type parameter but that did not work very well, so I abandoned that idea. > We chose to introduce an Accept-Crs request header to let the client negotiate a preferred CRS and a Content-Crs header to identify the CRS used in both the payload of the request as the payload of the response. @dvh where an API would be negotiating with a client for GeoJSON or KML for example, what value of `Accept-Crs` would be used (the axes in those formats, like MapML, are ordered [long,lat], which is defined only in the format and not by a well-known CRS identifier, IIRC)? -- GitHub Notification of comment by prushforth Please view or discuss this issue at https://github.com/w3c/sdw/issues/1058#issuecomment-409580206 using your GitHub account
Received on Wednesday, 1 August 2018 13:47:23 UTC