Subject: [Geojson] the extension/processing model discussion

From: Erik Wilde <[email-masked]>
Date: Mon, 4 Jan 2016 17:30:09 -0700

happy new year everybody!

just ran into this on twitter by roy fielding and thought this might be 
a good indication that a "processing model" indeed can be helpful when 
it comes to open information exchange:

"@fielding: REST is designed to steer developers toward handling change 
by observing and adapting to changes in content instead of interfaces." 
https://twitter.com/fielding/status/684110775313551360

"@fielding: And to do that we require protocols that self-describe and 
media types with well-defined rules for how to ignore (or not) unknown 
content." https://twitter.com/fielding/status/684111566304743424

to me, that sounds a lot like a well-defined model for how to handle an 
instance of a certain media type, and in particular rules about where to 
expect "extension" things, and how to process them.

cheers,

dret.

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

---

From: Sean Gillies <[email-masked]>
Date: Thu, 7 Jan 2016 15:25:11 -0700

Happy New Year to you, too!

On Mon, Jan 4, 2016 at 5:30 PM, Erik Wilde <[email-masked]> wrote:

> just ran into this on twitter by roy fielding and thought this might be a
> good indication that a "processing model" indeed can be helpful when it
> comes to open information exchange:
>
> "@fielding: REST is designed to steer developers toward handling change by
> observing and adapting to changes in content instead of interfaces."

I also saw this on Twitter and didn't get where he was coming from until I
revisited the replies and saw this one:
https://twitter.com/gala_santiago/status/684257794413998080. I don't think
we have the same situation in JSON, do we? In HTML, removing the tags from
around content doesn't necessarily break the content or the containing
element, but removing the key of a JSON object and leaving the value
definitely results in invalid JSON.

Say we have a HTML parser that doesn't know what the <blink> element is.
How is it supposed to understand whether to turn

  <p>Here is some <blink>text</blink></p>

into

  <p>Here is some text</p>

or

  <p>Here is some </p>

That's the question, yes? I don't see how this issue is relevant to
GeoJSON, because a JSON object value can't exist without its key. In other
words, for a GeoJSON parser that doesn't understand what the "query"
extension is,

  {"type": "FeatureCollection", "query": "419 Teapot Ln"}

can't become anything but

  {"type": "FeatureCollection"}

Or am I missing something?

-- 
Sean Gillies

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Jan 2016 09:54:11 +1100

You are comparing two different extension regimes, both equally valid.
The constraints on extensions are very different, of course.  (You can
have both at once if you put in the extra work too.)

On 8 January 2016 at 09:25, Sean Gillies <[email-masked]> wrote:
> Say we have a HTML parser that doesn't know what the <blink> element is. How
> is it supposed to understand whether to turn
>
> That's the question, yes? I don't see how this issue is relevant to GeoJSON,
> because a JSON object value can't exist without its key. In other words, for
> a GeoJSON parser that doesn't understand what the "query" extension is,
>
> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson
>

---

From: Erik Wilde <[email-masked]>
Date: Thu, 7 Jan 2016 16:23:42 -0700

On 2016-01-07 15:25, Sean Gillies wrote:
> I also saw this on Twitter and didn't get where he was coming from until
> I revisited the replies and saw this one:
> https://twitter.com/gala_santiago/status/684257794413998080. I don't
> think we have the same situation in JSON, do we? In HTML, removing the
> tags from around content doesn't necessarily break the content or the
> containing element, but removing the key of a JSON object and leaving
> the value definitely results in invalid JSON.

i wasn't proposing to adopt the HTML rule literally. and @fielding also 
is talking about REST in general, about the fact that these kind of 
rules help extension and openness and need to exist early on if they 
should allow this kind of evolution.

> GeoJSON, because a JSON object value can't exist without its key.

HTML's rule is to ignore unknown elements and "render" the content. that 
amount to the equivalent of the "text value" in XML. for HTML, that 
makes a lot of sense and is a smart rule to have.

for attributes, the rules are different. they must be ignored. maybe 
that's more what you have in mind?

either way, the important thing is that HTML has these rules that allow 
it to be extended and to evolve, without the need to have versioning in 
the media type. that's very smart. for JSON/GeoJSON, different rules may 
be better. all i wanted to say is that figuring out those rules and 
putting them into a spec is a Good Idea.

> In
> other words, for a GeoJSON parser that doesn't understand what the
> "query" extension is,

no, i don't think you're missing anything. what you're showing here is 
fine if you have a rule saying "there can be members other than 'type' 
and implementations must not stop processing and must ignore unknown 
members". this probably should be accompanied by a rule saying 
"additional members MUST NOT change the semantics of the 'type' member."

cheers,

dret.