-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pick a recommended encoding #25
Comments
Doh! I just argued in a previous SWG meeting that we should have no default because this line of reasoning is what locked us into GML for so many years. Instead -- I argued -- that like WMS, the client and server negotiation a mutually agreeable format. I also imagined that clients could use the OPTIONS method to get the available formats from the server. |
Darn, I need to get the SWG's on my calendar. I can see that argument, though for WMS png vs jpeg is a trivial implementation for most any software. JSON vs HTML I'd argue not so much (JSON vs naive XML sure, but not vs validating GML). Thinking about it, I think 'default' is actually more than I'd really need. But I do think at least a recommendation would be important though - if you're going to implement one format then make it this one. Hopefully a recommendation could be changed easier in the future, and not tie us like GML. I'd also feel a lot better about no default if we can do #24, so it's really just JSON and HTML, and each clearly has their purpose - one for humans, one for machines. |
There is also a consideration of picking one or more formats for conformance testing. That would make it at least a strong recommendation.
…--Josh
On Dec 13, 2017, at 6:14 PM, Chris Holmes ***@***.***> wrote:
Darn, I need to get the SWG's on my calendar. I can see that argument, though for WMS png vs jpeg is a trivial implementation for most any software. JSON vs HTML I'd argue not so much (JSON vs naive XML sure, but not vs validating GML).
Thinking about it, I think 'default' is actually more than I'd really need. But I do think at least a recommendation would be important though - if you're going to implement one format then make it this one. Hopefully a recommendation could be changed easier in the future, and not tie us like GML.
I'd also feel a lot better about no default if we can do #24, so it's really just JSON and HTML, and each clearly has their purpose - one for humans, one for machines.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
It is not clear to me what a "default" encoding is. I assume it is a mandatory encoding that everyone has to implement? I think the argument why we do not want to have a mandatory encoding is still valid. And even if we would assume that GeoJSON would be dominant encoding for spatial data for a long time, GeoJSON probably should not be the mandatory encoding for all cases as then you could not support, for example, 3D data. Which is why I still think that the current approach makes sense. |
What we need to discuss is who the intended consumer of this information is. In Map Markup Language, we've made the decision that Web browser developers are the target developer for MapML. The reason for this is interoperability: we want spatial information available to as broad a set of users as possible. HTML does this for information documents. MapML aims to do this for map documents. What kind of information is represented by HTML? Almost anything your heart desires to represent, except it's not great at spatial information, yet. ergo we need a specialized map document format for this, that leverages the strengths of the Web: hypertext and hyperlinks, In consideration of the foregoing, MapML provides a DOM-compatible format: if (when) browsers decide that maps should be part of their native semantics, they will be easily able to present DOM APIs over maps and spatial data that are then available to Web developers aka HTML authors. If the target customer of the format is Web developers, then you almost need look no further than GeoJSON support, since it is easily converted to JavaScript-compatible objects. If the map was a native browser object, GeoJSON could be presented to the Web developers via DOM APIs, I think. So, for your consideration, perhaps WFS 3.0 could also offer MapML as an output, and possibly make it the 'default', if browsers are the target. |
Fair points on the default - I just changed the title to 'recommended' encoding. I agree that mandatory encoding wouldn't be great, forcing people to implement it. What I'm really looking for is when a developer sits down to implement there's a clear recommendation of which encoding they should probably start with. A recommendation that says 'if you're unsure what to implement first this is the one you should start with'. Note that I think this recommendation could change in future versions - wfs 5.0 may have a recommendation of protobuf or some newfangled thing. |
Making people choose between HTML and JSON (as well as XML unless #24 is accepted) decreases interoperability if there is no guidance on which one must be supported. Some may choose HTML, some JSON, some XML.
It forces them to do additional thinking and research, or just go with their gut - but not matter what there is additional decision making.
It matters less what the default is, and indeed the second one can be strongly encouraged.
My gut often says HTML, but I've been convinced that it should be JSON. The primary consumer of WFS API's is machines, and it should be a clear machine readable format. HTML should be strongly encouraged, and indeed there likely could be open source libraries that make it really easy to turn the JSON responses in to useful HTML - even doing it on the fly in javascript.
The text was updated successfully, but these errors were encountered: