[GeoJSON] properties on FeatureCollection objects.

[Sean Gillies]

Thanks for pointing out the hole in my argument about collisions, Erik.

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

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.




On Sat, May 18, 2013 at 12:28 AM, Stefan Drees <stefan at drees.name> wrote:

> 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
>
>
> ______________________________**_________________
> GeoJSON mailing list
> GeoJSON at lists.geojson.org
> http://lists.geojson.org/**listinfo.cgi/geojson-geojson.**org<http://lists.geojson.org/listinfo.cgi/geojson-geojson.org>
>



-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20130519/32f20c9e/attachment-0005.htm>