Subject: [Geojson] issue #64

From: Erik Wilde <[email-masked]>
Date: Tue, 26 Jan 2016 19:08:13 -0800

hello.

https://github.com/geojson/draft-geojson/issues/64 is still open and 
talks about the possibility to use JSON text sequences (RFC 7464) for 
representing more than one GeoJSON object.

my proposal to close this issue is as follows:

- the GeoJSON draft will not introduce such a facility.

- the GeoJSON draft will have an informal appendix mentioning the fact 
that if people want to represent more than one GeoJSON object, then they 
might want to look at RFC 7464.

- the GeoJSON draft could also mention that it is possible that there 
will be a later draft on "GeoJSON text sequences", but that currently no 
such draft is under development.

please keep discussions about this (and other issues) on the list. our 
goal is to use github issues only for tracking issues and issue 
resolution, but to use the list for all discussions.

thanks a lot and cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: Allan Doyle <[email-masked]>
Date: Wed, 27 Jan 2016 12:28:19 -0500

> On Jan 26, 2016, at 10:08 PM, Erik Wilde <[email-masked]> wrote:
> 
> hello.
> 
> https://github.com/geojson/draft-geojson/issues/64 is still open and talks about the possibility to use JSON text sequences (RFC 7464) for representing more than one GeoJSON object.
> 

+1

> 
> - the GeoJSON draft will have an informal appendix mentioning the fact that if people want to represent more than one GeoJSON object, then they might want to look at RFC 7464.

+1

> 
> - the GeoJSON draft could also mention that it is possible that there will be a later draft on "GeoJSON text sequences", but that currently no such draft is under development.

0 - I can see the value of pointing towards this, but at the same time, if we did the above two things, that should be enough.

> 
> please keep discussions about this (and other issues) on the list. our goal is to use github issues only for tracking issues and issue resolution, but to use the list for all discussions.
> 
> thanks a lot and cheers,
> 
> dret.
> 
> -- 
> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Jan 2016 04:37:32 +1100

>> - the GeoJSON draft will have an informal appendix mentioning the fact that if people want to represent more than one GeoJSON object, then they might want to look at RFC 7464.

A caution here.  A statement like that could be construed as being
normative if we're not careful and I believe that to do this properly,
you would need to define a media type.

If someone could propose text for that section, I think that it might
help clarify a bit.  (Just send a paragraph to the list.)

---

From: Tim Schaub <[email-masked]>
Date: Wed, 27 Jan 2016 11:31:21 -0700

On Tue, Jan 26, 2016 at 8:08 PM, Erik Wilde <[email-masked]> wrote:
> hello.
>
> https://github.com/geojson/draft-geojson/issues/64 is still open and talks
> about the possibility to use JSON text sequences (RFC 7464) for representing
> more than one GeoJSON object.
>

+1

> - the GeoJSON draft will have an informal appendix mentioning the fact that
> if people want to represent more than one GeoJSON object, then they might
> want to look at RFC 7464.

+1

> - the GeoJSON draft could also mention that it is possible that there will
> be a later draft on "GeoJSON text sequences", but that currently no such
> draft is under development.

-1

I would hope the two specs could be used together, without needing a
third that describes them combined.  Maybe instructions on using
GeoJSON Feature objects in a JSON Text Sequence.  But I don't see the
need for another spec (or another draft of the GeoJSON spec).

Tim

> please keep discussions about this (and other issues) on the list. our goal
> is to use github issues only for tracking issues and issue resolution, but
> to use the list for all discussions.
>
> thanks a lot and cheers,
>
> dret.
>
> --

---

From: Erik Wilde <[email-masked]>
Date: Wed, 27 Jan 2016 10:32:23 -0800

> you would need to define a media type.

yes, absolutely. it's an informal appendix, so i think you would need to 
be very determined to understand it as meaning something normative.

> help clarify a bit.  (Just send a paragraph to the list.)

https://github.com/geojson/draft-geojson/pull/132

-------------------------------------------

GeoJSON Text Sequences

GeoJSON as defined in this specification consists of exactly one GeoJSON 
object. However, there may be cases in which application want to 
represent sets or sequences of GeoJSON objects. Representing sets or 
sequences of GeoJSON objects is outside of the scope of this specification.

If such a representation is needed, a new media type is required that 
has the ability to represent sets or sequences. When defining such a 
media type, it may be useful to base it on "JSON Text Sequences" 
[RFC7464], leaving the foundations of how to represent multiple JSON 
objects to that specifications, and only defining how it applies to 
GeoJSON objects. However, no such definition is included here, and at 
the time of writing it is unclear if and when there will be a 
specification for "GeoJSON Text Sequences".

-------------------------------------------

feedback very welcome! please send feedback to the list instead of 
commenting on the PR. thanks!

cheers,

dret.

---

From: Erik Wilde <[email-masked]>
Date: Wed, 27 Jan 2016 10:36:16 -0800

hello tim.

>> want to look at RFC 7464.

that's a solid +2! ;-)

> need for another spec (or another draft of the GeoJSON spec).

well, luckily there's no need for us to decide on that. but i do think 
that you probably would need a separate spec and media type, for example 
saying if/how you're allowed to mix-in other object types, or whether 
you are only allowed to use GeoJSON objects (and in that latter case, 
what to do if this constraint is violated).

anyway, it looks as if we have good consensus so far, and i have sent a 
proposal to the list. mentioning the possibility of such an additional 
spec in my eyes does not do any damage, but if people dislike it, then 
we can just leave that open.

thanks and cheers,

dret.