Subject: [Geojson] Reserialization is hard

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Nov 2015 15:16:13 -0800

It looks as though Sean's proposal is getting some support, but I
thought that I'd call something out here:

+Implementations that parse and then reserialize GeoJSON documents that
+contain extension properties SHOULD take sufficient care to ensure that
+extension properties used within the original document are preserved and
+serialized appropriately.

In my experience, there are two types of reserializers.

1. The first takes everything and passes it on.  This is often when
the data needs to transition through some intermediate format.  The
most trivial being JSON.serialize(JSON.parse(geojson)).

2. The second aims to sanitize data.  These will understand some
extensions and will do what they will to those things that they
understand.  However, we do not provide enough rules to guarantee the
different modes of operation here.

The passthrough option is trivial to handle.  However, we should note
that order of dictionary attributes is not important and MUST NOT be
relied upon to carry semantics.

The sanitizing reserializer is harder.  If the intent is to remove
stuff that might cause problems, then you have to define a rule that
states that an extension cannot modify the semantics of ANOTHER
extension.  Otherwise you get into a situation where the processor
understands extension A and takes actions based on that understanding,
without knowing that extension B has modified the semantics of A in an
incompatible fashion.  That means that a sanitizing reserializer is
then able to modify what it understands and leave the rest alone.  OR
the sanitizing reserializer is able to modify what it understands and
remove the rest.

For that to work, you must also prohibit the partial removal of
extensions that you don't understand, or define rules around atomicity
of extensions (i.e., how attributes added to different extension
points are permitted to interact).  I think that prohibiting partial
removal is safest.

I would also suggest that any processor that performs any modification
of any data (core or extension) should remove unsupported extensions.
If, for example, an extension to a polygon attached time values to
each point, then leaving that information around after the processor
changed the polygon into another shape would be quite confusing.

I'm not particularly enamoured with the notion that someone might
combine features that had unsupported extensions.