Skip to content
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

Closed
cholmes opened this issue Dec 13, 2017 · 6 comments · Fixed by #29
Closed

Pick a recommended encoding #25

cholmes opened this issue Dec 13, 2017 · 6 comments · Fixed by #29

Comments

@cholmes
Copy link
Member

cholmes commented Dec 13, 2017

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.

@pvretano
Copy link
Contributor

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.
Since the number of choices is small anyway and it seems like JSON is emerging as a defacto standard anyway I don't think that leaving it open ended will harm interoperability that much.

@cholmes
Copy link
Member Author

cholmes commented Dec 13, 2017

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.

@lieberjosh
Copy link

lieberjosh commented Dec 14, 2017 via email

@cportele
Copy link
Member

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.

@prushforth
Copy link

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.

@cholmes cholmes changed the title Pick a default encoding Pick a recommended encoding Dec 15, 2017
@cholmes
Copy link
Member Author

cholmes commented Dec 15, 2017

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.

cportele added a commit that referenced this issue Jan 8, 2018
* add recommendation on GeoJSON in the Core
* add discussion about encodings and the recommendations in Clause 6
(Overview)
* reference discussion from clauses 2, 7 and 8

resolves #25
@cportele cportele mentioned this issue Jan 8, 2018
@cportele cportele self-assigned this Jan 26, 2018
@cportele cportele added this to the Part 1, First Draft milestone Jan 29, 2018
cportele added a commit that referenced this issue Jan 30, 2018
The text, OpenAPI fragments and examples now focus on HTML and JSON.

Resolves #19 (together with #25/#29).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants