[GeoJSON] properties on FeatureCollection objects.

[Erik Wilde]

hello sean.

at the risk of sounding pedantic, but nonetheless i think this is 
something that's important, so here i go...

On 2013-05-19 10:14 , Sean Gillies wrote:
> I was rereading Douglas Crockford's slides from XML 2006 (abridged at
> http://www.json.org/fatfree.html) and I think that must-ignore is
> in there already, if not explicitly written in RFC 4267. He writes that
>    "JSON is flexible. New fields can be added to existing structures
> without obsoleting existing programs."

that's true as long as existing programs don't break when they find new 
fields. most JSON-based implementations certainly don't, but that really 
isn't something that's "part of JSON".

> Isn't this statement, in combination with the sentence in section 4 of
> RFC 4267 that reads
>    "A JSON parser MUST accept all texts that conform to the JSON grammar."
> close to the essence of must-ignore? If a parser must accept all
> conforming data, it practically must ignore unexpected fields to avoid
> breaking.
> 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.

there are two layers here:

- parsing JSON into an object structure, and then making sense of that 
structure in GeoJSON. parsing shouldn't break, and won't in pretty much 
all JSON libraries out there (because JSON really is free-form and not 
as schema-minded as XML or other languages, where you can already 
constrain parsing through declarative means such as schemas).

- one you have the "parse tree", you must make sense of it. this is up 
for the format to define. just to explain the difference (and GeoJSON 
won't use this, but it illustrates the point): if you had 
"mustUnderstand" semantics, then if the the parse tree contained 
extensions that were carrying that label, and the code processing it 
wouldn't understand those extensions, then it would need to stop 
processing, because the format processing rules said so (and that's 
completely separate from the initial parsing step).

from an implementation standpoint, it help when a format clearly 
separates these two parts: how to use the serialization syntax (which in 
JSON really is not that easy to say, because there is not such a rich 
ecosystem of layered standards as there is for example in XML), and how 
to process whatever is the result of that first step. it makes it easier 
for implementers, and it also help to make otherwise implicit 
assumptions explicit, reducing the risk of implementers making decisions 
that may compromise interoperability.

cheers,

dret.