Subject: [Geojson] Extending GeoJSON, revised

From: Sean Gillies <[email-masked]>
Date: Sun, 29 Nov 2015 23:06:38 -0700

Dear all,

Based on last week's discussion, I've made the following update to the
extensibility section of the draft:

https://github.com/geojson/draft-geojson/commit/2b60aecf3774245f3bb9d5bf6fc81632471faf32

with an explanation at

  https://github.com/geojson/draft-geojson/pull/117#issuecomment-160523621

The re-serialization and aggregation sections are removed. The must-ignore
policy for foreign properties stays. This makes GeoJSON's extensibility
story more like Atom's than Activity Stream's.

I still don't understand why GeoJSON implementations should be allowed to
fail and error out when hitting foreign properties like Carmen's "query" or
Overpass's "timestamp" instead of just skipping them as recommended by
I-JSON: https://tools.ietf.org/html/draft-ietf-json-i-json-06#section-4.2.

-- 
Sean Gillies

---

From: Calvin Metcalf <[email-masked]>
Date: Mon, 30 Nov 2015 12:03:46 +0000

This is good as the don't halt and catch fire rule is already in place
specifically for the top level geojson object and many (well at least me)
have interpreted it to apply to objects at all levels so the clarification
is very welcome.

On Mon, Nov 30, 2015, 1:06 AM Sean Gillies <[email-masked]> wrote:

> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson
>

---

From: Martin Daly <[email-masked]>
Date: Mon, 30 Nov 2015 15:19:01 +0000

This rewording works for me.

I don’t feel strongly (in the way that Allan does) about MUST NOT or SHOULD NOT wrt handling “foreign properties”, and would accept either.

Martin

From: GeoJSON [mailto:[email-masked]] On Behalf Of Sean Gillies
Sent: 30 November 2015 06:07
To: [email-masked]
Subject: [Geojson] Extending GeoJSON, revised

Dear all,

Based on last week's discussion, I've made the following update to the extensibility section of the draft:

The re-serialization and aggregation sections are removed. The must-ignore policy for foreign properties stays. This makes GeoJSON's extensibility story more like Atom's than Activity Stream's.

I still don't understand why GeoJSON implementations should be allowed to fail and error out when hitting foreign properties like Carmen's "query" or Overpass's "timestamp" instead of just skipping them as recommended by I-JSON: https://tools.ietf.org/html/draft-ietf-json-i-json-06#section-4.2.
--
Sean Gillies

---

From: Allan Doyle <[email-masked]>
Date: Mon, 30 Nov 2015 10:44:44 -0500

One last time and then I’ll stop and accept the majority view.

- GeoJSON is a format spec and does not claim to be a protocol or API spec.

- Processors are untestable against the spec as it stands

- I don’t understand why people want to single out just one so-called good behavior of a processor.

- Processors are meant to be market-driven, in the broad sense of the word. If the market likes a processor, it will get used, if it doesn’t it won’t. If the market requires a non-halting processor (and I’m guessing that 99.9% of the market will), then the market will reject halting processors and life will go on. (I note that the market liked GeoJSON just fine in its original form at GeoJSON.org and had little heartburn about halting processors.)

- GeoJSON references JSON and I-JSON, and I’d be happy with stronger wording that reinforces those references.

- It’s not really correct to refer to I-JSON’s 4.2 by paraphrasing the must-ignore policy the way it currently is done. I’d rather see a strong reference to i-JSON section 4 in its entirety.

I will now yield to the wisdom of the group.

	Allan

> On Nov 30, 2015, at 10:19 AM, Martin Daly <[email-masked]> wrote:
> 
>   <>
>   https://github.com/geojson/draft-geojson/commit/2b60aecf3774245f3bb9d5bf6fc81632471faf32 <https://github.com/geojson/draft-geojson/commit/2b60aecf3774245f3bb9d5bf6fc81632471faf32>
> with an explanation at
> 
>   https://github.com/geojson/draft-geojson/pull/117#issuecomment-160523621 <https://github.com/geojson/draft-geojson/pull/117#issuecomment-160523621>
>  
> I still don't understand why GeoJSON implementations should be allowed to fail and error out when hitting foreign properties like Carmen's "query" or Overpass's "timestamp" instead of just skipping them as recommended by I-JSON: https://tools.ietf.org/html/draft-ietf-json-i-json-06#section-4.2 <https://tools.ietf.org/html/draft-ietf-json-i-json-06#section-4.2>.
> 
> -- 
> Sean Gillies