<div dir="ltr"><div><div><div><div>Thanks for pointing out the hole in my argument about collisions, Erik.<br></div><br>I was rereading Douglas Crockford's slides from XML 2006 (abridged at <a href="http://www.json.org/fatfree.html">http://www.json.org/fatfree.html</a>) and I think that must-ignore is <br>
in there already, if not explicitly written in RFC 4267. He writes that<br><br>  "JSON is flexible. New fields can be added to existing structures without obsoleting existing programs."<br><br></div>Isn't this statement, in combination with the sentence in section 4 of RFC 4267 that reads<br>
<br>  "A JSON parser MUST accept all texts that conform to the JSON grammar."<br><br></div>close to the essence of must-ignore? If a parser must accept all conforming data, it practically must ignore unexpected fields to avoid breaking.<br>
<br></div>In the end, though, I'm not sure a GeoJSON I-D needs to make any more mention of processing rules than RFC 4267 does, which is very little.<br><div><div><br><br></div></div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Sat, May 18, 2013 at 12:28 AM, Stefan Drees <span dir="ltr"><<a href="mailto:stefan@drees.name" target="_blank">stefan@drees.name</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Erik,<br>
<br>
not responding to my own post, only amending it ;-)<br>
<br>
TL;DR: For one to give my feedback on the namespace assertion Erik's mail and also soften a bit my proposal basing GeoJSON on the Robustness Principle.<br>
<br>
Further details inline below.<div class="im"><br>
<br>
On 18.05.13 07:37, Stefan Drees wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 18.05.13 00:05, Erik Wilde wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...<br>
From: *Sean Gillies* <<a href="mailto:sean.gillies@gmail.com" target="_blank">sean.gillies@gmail.com</a>><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You can add objects freely to your GeoJSON<br>
and unless they collide with the objects we're specifying in the GeoJSON<br>
profile, you can't trouble anybody.<br>
</blockquote>
<br>
well, that's not entirely true as somebody's naming choices might<br>
collide with the naming choices of somebody else out there. however,<br>
while XML has well-established ways of how to handles this in a<br>
well-defined way (namespaces), JSON doesn't, but the general consensus<br>
seems to be that people don't want to invent namespaces for their JSON<br>
format.<br>
</blockquote></blockquote>
<br></div>
I guess the latter statement about JSON and namespaces is at least debateable in its meaning and its distribution assertion is losing grounds.<br>
<br>
The need and urge for namespacing ("fences") in JSON is growing IMO, as javascript on client and server side alike spread fast and also JSON as a light and versatile data container has been accepted by many wider "audiences" / communities each having their own shared "vocabularies".<br>

<br>
In JSON due to security considerations, you are adviced (as a service provider) to distribute your messages inside an outer wrapper object (to guard against attacks appending elements to a JSON array as outer element). So inside such a message all members sit inside one root object, which implies without further knowledge of what actually constitues the "thing" there is a need for a) well-chosen unambiguous names or b) prefixes where I see many reasons for the latter (b) and only few (as also concluded above in the "naming choices" part) for the former (a).<br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

and "mustIgnore" really isn't part of JSON. it's just part of the<br>
processing model of most JSON-based representations (and often more<br>
implicitly than explicitly so). i think it would help a lot to make the<br>
processing model explicit and define how GeoJSON is supposed to be<br>
consumed.  ...<br>
</blockquote>
<br>
IMO it is necessary to draw a line between the two positions mentioned<br>
here as a mere indication where the responsibility of the GeoJSON I-D<br>
ends and where the producer-consumer-relationship enforces additional<br>
rules that only depend on the instance pair of the communication channel<br>
and not on the general case.<br>
<br>
What about starting from the Robustness Principle (a.k.a. Postel’s law)<br>
cf. [RFC1122]: “Be liberal in what you accept, and conservative in what<br>
you send“. A GeoJSON consumer is expected to “ignore” instead “complain<br>
about” any “unknown stuff” present in a response and still make the most<br></div>
of it. ...<br>
</blockquote>
<br>
Softening my suggestion of a starting point a bit: I know we describe 1) a format here and do not specify 2) a protocol plus a format.<br>
<br>
In the case of (2) we would have a no-brainer jump-start with Postel's Law, but as we only (as of now) describe one part of the "equation", we might put some rules inside our format spec (at minimum attributed with SHOULDs and SHOULD NOTs as applicable) ensuring that (where forseeable) not the complete burden ends up on the consumer/clients shoulders.<br>

<br>
If one specifies a complete comunication protocol, both sides (producer and consumer) are declared to be known up to a certain detail and are assigned roles where a balance is sought (and the terms and places are all present to specify this) for sharing the burdens.<br>

<br>
In our case we should IMO as far as possible precisely as you (Erik) suggested: "[...] make the processing model explicit and define how GeoJSON is supposed to be consumed." with the reasoning, that it fosters producer-consumer relationships by minimizing any impedance mismatch.<br>

<br>
But, this will not be easy, as we do not describe a protocol, only a format (as focus). On the other hand, if the GeoJSON community knows, that in reality there has been a consolidation on some describable processing model, this would be a good starting point to be helpful in offering guidance without writing something that is "wrong" in n percent of the use cases.<br>

<br>
We should maybe split processing and namespacing into two different threads.<br>
<br>
All the best,<br>
<br>
Stefan<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
GeoJSON mailing list<br>
<a href="mailto:GeoJSON@lists.geojson.org" target="_blank">GeoJSON@lists.geojson.org</a><br>
<a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org" target="_blank">http://lists.geojson.org/<u></u>listinfo.cgi/geojson-geojson.<u></u>org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Sean Gillies
</div>