<div dir="ltr">On Fri, Sep 16, 2016 at 4:41 AM, Jeff Yutzler <span dir="ltr"><<a href="mailto:jeffy@imagemattersllc.com" target="_blank">jeffy@imagemattersllc.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">List,<div>One of the things I appreciated about GeoJSON early on is that it is not rigid when it comes to properties in the features in a feature collection. The very first example in the spec shows different properties in different features. I have been able to take advantage of this design decision to simplify my own code and to avoid brittle feature schemas. </div><div><br></div><div>I am finding that other code bases do not react well to this technique. It appears the way they work is that the first feature in a feature collection is used as a template. If any properties appear in subsequent features that are not in the template, the operation may fail. To work around these failures, I find myself doing immoral things to the features[1].</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>While I don't expect any normative changes in the specification, I would like to know more about the expected behavior when applications see unexpected properties. If it were up to me, I would expect applications to accept any valid GeoJSON gracefully. However, I am willing to be convinced otherwise.</div><div><br></div><div>Thanks,</div><div>Jeff<div><br></div><div>[1] <a href="https://github.com/venicegeo/geojson-go/commit/d2c793d8209686951cc87f80c1c0aba5d64dfef9" target="_blank">https://github.com/veniceg<wbr>eo/geojson-go/commit/d2c793d82<wbr>09686951cc87f80c1c0aba5d64dfef<wbr>9</a></div></div></div></blockquote><div><br></div><div>Jeff,<br><br></div><div>I agree that applications should accept any valid GeoJSON gracefully, whether it meets their expectations or not. It's widely recognized that JSON is flexible like this. See <a href="http://www.json.org/fatfree.html" target="_blank">http://www.json.org/fatfree.ht<wbr>ml</a>, in which Douglas Crockford asserts<br><br>> JSON is flexible. New fields can be 
  added to existing structures without obsoleting existing programs.<br><br>Or <a href="https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json" target="_blank">https://www.mnot.net/blog/2011<wbr>/10/12/thinking_about_namespac<wbr>es_in_json</a>, in which Mark Nottingham writes<br><br>> JSON has a head start in that it embodies the mustIgnore rule; if you 
put extra data in a JSON document (for example, an extra property on an 
object), all implementations will just ignore it.<br><br></div><div>In my view, applications that do not ignore extra properties are broken. Excepting ones that are written specifically to detect whether features have homogeneous properties. We had a discussion about in November 2015 and several of us strenuously objected to any "mustIgnore" language in the spec, which is why the spec doesn't recommend what you, I, and others recognize to be a best practice.<br><br></div>How to tell applications what to expect in GeoJSON *before* reading it is something we might try to solve together. I've seen firsthand that the use of the first or first N features to diagnose a schema can fail spectacularly.<br><br></div>-- <br><div>Sean Gillies</div>
</div></div>