[GeoJSON] properties on FeatureCollection objects.

[Stefan Drees]

On 18.05.13 00:05, Erik Wilde wrote:
> ...
> From: *Sean Gillies* <sean.gillies at gmail.com>
>> You can add objects freely to your GeoJSON
>> and unless they collide with the objects we're specifying in the GeoJSON
>> profile, you can't trouble anybody.
>
> well, that's not entirely true as somebody's naming choices might
> collide with the naming choices of somebody else out there. however,
> while XML has well-established ways of how to handles this in a
> well-defined way (namespaces), JSON doesn't, but the general consensus
> seems to be that people don't want to invent namespaces for their JSON
> format.
>
> and "mustIgnore" really isn't part of JSON. it's just part of the
> processing model of most JSON-based representations (and often more
> implicitly than explicitly so). i think it would help a lot to make the
> processing model explicit and define how GeoJSON is supposed to be
> consumed.  ...

IMO it is necessary to draw a line between the two positions mentioned 
here as a mere indication where the responsibility of the GeoJSON I-D 
ends and where the producer-consumer-relationship enforces additional 
rules that only depend on the instance pair of the communication channel 
and not on the general case.

What about starting from the Robustness Principle (a.k.a. Postel’s law) 
cf. [RFC1122]: “Be liberal in what you accept, and conservative in what 
you send“. A GeoJSON consumer is expected to “ignore” instead “complain 
about” any “unknown stuff” present in a response and still make the most 
of it.

All the best,

Stefan.