[GeoJSON] properties on FeatureCollection objects.

[Stefan Drees]

Hi Erik,

not responding to my own post, only amending it ;-)

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.

Further details inline below.

On 18.05.13 07:37, Stefan Drees wrote:
> 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.

I guess the latter statement about JSON and namespaces is at least 
debateable in its meaning and its distribution assertion is losing grounds.

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".

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).

>> 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. ...

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.

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.

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.

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.

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.

We should maybe split processing and namespacing into two different threads.

All the best,

Stefan