Subject: [Geojson] attempt to close #97

From: Erik Wilde <[email-masked]>
Date: Mon, 1 Feb 2016 17:01:13 -0800

hello.

https://github.com/geojson/draft-geojson/issues/97 is still open and 
there is some discussion in the issue. please let's keep any future 
discussion on the list.

#97 proposes to support RFC 6906 as a way how GeoJSON can advertise that 
a certain profile (as defined by RFC 6906) is used. this most likely 
would come down to supporting a "profile" member on the top level (with 
the value being a list of URIs), and support for an optional "profile" 
media type parameter.

what this is specifically *not* proposing to do is these two things:

- define one specific way how a profile is defined. as long as some use 
of GeoJSON follows the general openness/extension rules of GeoJSON, then 
somebody can document that, call it a profile, and identify it via URI. 
this URI then can be used to request/identify GeoJSON following that set 
of rules.

- define one specific way how a profile is documented. if somebody 
creates a profile, they may just document it in human-readable form. 
other may prefer machine-readable formats, and pick the one that best 
suits their needs.

the idea of this is to support loose coupling. people defining profiles 
can do so in a way that best suits their needs. and anybody not 
interested in even knowing that profiles exist can simply ignore them 
and treat GeoJSON as before, assuming that extensions are a "bag of 
stuff" that you learn about by inspecting the GeoJSON object.

please let's not rehash the debate about "what good is machine 
identification without machine description?" it is a different 
discussion. RFC 6906 is specifically about cleanly separating these two 
things, and so is #97.

thanks and cheers,

dret.

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

---

From: Sean Gillies <[email-masked]>
Date: Mon, 8 Feb 2016 13:42:24 -0700

Erik,

On Mon, Feb 1, 2016 at 6:01 PM, Erik Wilde <[email-masked]> wrote:

> #97 proposes to support RFC 6906 as a way how GeoJSON can advertise that a
> certain profile (as defined by RFC 6906) is used. this most likely would
> come down to supporting a "profile" member on the top level (with the value
> being a list of URIs), and support for an optional "profile" media type
> parameter.
>

> - define one specific way how a profile is defined. as long as some use of
> GeoJSON follows the general openness/extension rules of GeoJSON, then
> this URI then can be used to request/identify GeoJSON following that set of
> rules.
>

> - define one specific way how a profile is documented. if somebody creates
> a profile, they may just document it in human-readable form. other may
> prefer machine-readable formats, and pick the one that best suits their
> needs.
>

> can do so in a way that best suits their needs. and anybody not interested
> in even knowing that profiles exist can simply ignore them and treat
> GeoJSON as before, assuming that extensions are a "bag of stuff" that you
> learn about by inspecting the GeoJSON object.
>
> identification without machine description?" it is a different discussion.
> RFC 6906 is specifically about cleanly separating these two things, and so
> is #97.
>
> thanks and cheers,
>
> dret.
>

I'm +1 on this. I'm part author of several extensions and look forward to
being able to indicate that I'm using those extensions in a
application/geo+json document.

-- 
Sean Gillies

---

From: Martin Daly <[email-masked]>
Date: Mon, 8 Feb 2016 22:46:43 +0000

-1

Martin

---

From: Erik Wilde <[email-masked]>
Date: Mon, 8 Feb 2016 15:06:20 -0800

hello martin.

would you care to elaborate? do you dislike the idea of making 
extensions discoverable, or the proposed execution?

thanks,

dret.

---

From: Martin Daly <[email-masked]>
Date: Tue, 9 Feb 2016 14:34:00 +0000

> > -1
> 
> would you care to elaborate? do you dislike the idea of making extensions
> discoverable, or the proposed execution?

Extensions *without* machine-readable descriptions lack utility. Extensions *with* machine-readable descriptions are (necessarily) complex, and thus against the fundamental principle of simplicity applied throughout GeoJSON.

This change, whether intentionally or not, is a Trojan horse for a future RFC that prescribes what the RFC 6906 must resolve to, which will either be non-machine-readable, and therefore lack utility, or will be machine-readable, and therefore too complex for GeoJSON.

Ergo -1.

Martin

---

From: Erik Wilde <[email-masked]>
Date: Tue, 9 Feb 2016 07:50:05 -0800

On 2016-02-09 6:34 , Martin Daly wrote:
> Extensions *without* machine-readable descriptions lack utility.

maybe they lack utility from your point of view, and you don't have to 
use profiles if you don't want to. others (such as sean) have expressed 
an interest to be able to do that, so they do see utility.

> Extensions *with* machine-readable descriptions are (necessarily) complex, and thus against the fundamental principle of simplicity applied throughout GeoJSON.

agreed. but RFC 6906 is clear about the fact that the profile URI is a 
self-describing identifier, so there's no need to be worried.

> This change, whether intentionally or not, is a Trojan horse for a future RFC that prescribes what the RFC 6906 must resolve to, which will either be non-machine-readable, and therefore lack utilit…

there is no such explicit or implicit plan, and RFC 6906 disallows this 
anyway. the only plan and goal is to allow *self-describing 
identifiers*, thus making the mechanism simple. if people also make 
their profile URIs resolvable, then that is beyond our control, but 
there never can be a requirement to do so.

cheers,

dret.

---

From: Martin Daly <[email-masked]>
Date: Tue, 9 Feb 2016 16:44:40 +0000

> agreed. but RFC 6906 is clear about the fact that the profile URI is a self-
> describing identifier, so there's no need to be worried.

The URI might be self-describing, but the extension isn't. Hence it lacks utility.

> there is no such explicit or implicit plan, and RFC 6906 disallows this anyway. the
> only plan and goal is to allow *self-describing identifiers*, thus making the
> mechanism simple. if people also make their profile URIs resolvable, then that is
> beyond our control, but there never can be a requirement to do so.

Any future RFC can introduce any requirement that it sees fit. So a future "GeoJSON Extensions RFC", for example, could refer back to the proposed Trojan horse in this RFC, and easily add such a requirement. No Trojan horse means no future liability.

I've looked in my crystal ball too, and I see a different future.

Martin

---

From: Erik Wilde <[email-masked]>
Date: Tue, 9 Feb 2016 09:06:17 -0800

hello martin.

> The URI might be self-describing, but the extension isn't. Hence it lacks utility.

if we look at media types, which have self-describing identifiers but no 
self-describing specification, by your reasoning they lack utility as 
well? self-describing identifiers are a robust web pattern.

and just repeating: if you dislike this capability, then just don't use 
it. it's not mandatory and if you like to keep doing what you're doing, 
it doesn't change anything for you.

> Any future RFC can introduce any requirement that it sees fit.

no, that's incorrect. if profile is optional and has no requirement to 
make the URIs resolvable, then you cannot change this without breaking 
the media type *and* RFC 6906, and having to mint a new media type and a 
new, incompatible variant of RFC 6906.

> So a future "GeoJSON Extensions RFC", for example, could refer back to the proposed Trojan horse in this RFC, and easily add such a requirement. No Trojan horse means no future liability.

there's nothing to fear, there is no trojan horse. if somebody wanted to 
create a self-description mechanism, here is the only way this can 
happen given the starting point that we have:

- define this format and give it a media type.

- start minting and using profile URIs that resolve to descriptions 
using this media type.

- write code that, presented with an unknown profile URI, will attempt a 
GET requesting said media type.

- if no such representation can be fetched, fall back to the 
understanding that you have encountered an unknown profile that is not 
described using the new self-description mechanism.

this is the *only* way this can be done based on how GeoJSON and RFC 
6906 are defined, and it does not have the implications you seem to be 
fearful of.

> I've looked in my crystal ball too, and I see a different future.

i do agree that if the scenario you described would be a possible 
future, that would be bad and should be avoided. but it isn't.

if you don't want to use profile identifiers, that's one thing and 
you're free to ignore them. and if you have reasons to dislike them 
based on possible futures, that's fine, too.

cheers,

dret.

---

From: Martin Daly <[email-masked]>
Date: Tue, 9 Feb 2016 22:52:01 +0000

> and just repeating: if you dislike this capability, then just don't use it. it's not
> mandatory and if you like to keep doing what you're doing, it doesn't change
> anything for you.

You have this argument completely arse-about-face.

You don't have to use GeoJSON at all. However, if you want to then you are allowed to add (what are now known as) "Foreign Properties" to GeoJSON. It doesn't change anything for you whether "profile" is in the RFC or not.

A wise man once said, on this very list, "I still need to be convinced that there will be a meltdown if the spec remains essentially neutral on the topic of extensions." That remains the case.

Ultimately, I strongly favour maximally interoperable GeoJSON (as proven over several years now) over minimally extensible GeoJSON.

Martin

---

From: Erik Wilde <[email-masked]>
Date: Tue, 9 Feb 2016 14:57:10 -0800

hello martin.

> Ultimately, I strongly favour maximally interoperable GeoJSON (as proven over several years now) over minimally extensible GeoJSON.

no argument about interop, that's something we all deeply care about. 
but i still haven't heard a reason why the ability to signal a "profile" 
via a self-describing identifier, if one is so inclined, has any 
negative effect on interop.

cheers,

dret.

---

From: Martin Daly <[email-masked]>
Date: Tue, 9 Feb 2016 23:01:54 +0000

> > Ultimately, I strongly favour maximally interoperable GeoJSON (as proven over
> several years now) over minimally extensible GeoJSON.
> 
> via a self-describing identifier, if one is so inclined, has any negative effect on
> interop.

My experience informs my opinion, as your experience informs yours.

You are the one who has to make the case here - for "profile" improving the spec - because it is not there at the moment. So far, you have failed to do so.

I'm happy with the status quo, and remain -1 on adding "profile".

Martin

---

From: Erik Wilde <[email-masked]>
Date: Tue, 9 Feb 2016 15:05:27 -0800

hello all.

> I'm happy with the status quo, and remain -1 on adding "profile".

valid points. so far the feedback has been modest. we have one +1 from 
sean, and one -1 from martin. that's probably not enough support to 
justify the proposed "profile".

more feedback on the list would be helpful to decide either way. if we 
don't get that, then i suggest to close #97 without adding the proposed 
"profile" capability.

cheers,

dret.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Feb 2016 19:55:06 +1100

On 10 February 2016 at 10:05, Erik Wilde <[email-masked]> wrote:
> more feedback on the list would be helpful to decide either way. if we don't
> get that, then i suggest to close #97 without adding the proposed "profile"
> capability.

I'm not going to express my opinion, but I might observe that it's
possible to add profiles as an extension.   Or does the argument for
profiles state that it would have to be a commonly recognized
extension if disparate users of the format were looking to use it to
signal to each other what profiles were in use?

---

From: Erik Wilde <[email-masked]>
Date: Wed, 10 Feb 2016 07:17:35 -0800

hello martin.

> signal to each other what profiles were in use?

you are correct that people can start using the "profile" key in the way 
you describe, using it as part of their extension. but #97 goes a little 
further than that mostly in two ways:

- by adding a "profile" media type parameter, profile identifiers can be 
exposed on the HTTP level, allowing profiles to be identified and used 
in HTTP interactions such as requesting preferred profiles.

- since GeoJSON can conform to more than one profile, the "profile" key 
would allows lists/sets of URIs. if two extension defined their own 
profile mechanism via the "profile" key, then combining them would be 
tricky and probably not be done uniformly by different users.

cheers,

dret.

---

From: Sean Gillies <[email-masked]>
Date: Sat, 13 Feb 2016 16:03:37 -0700

On Wed, Feb 10, 2016 at 8:17 AM, Erik Wilde <[email-masked]> wrote:

>>> don't
> exposed on the HTTP level, allowing profiles to be identified and used in
> HTTP interactions such as requesting preferred profiles.
>
> would allows lists/sets of URIs. if two extension defined their own profile
> mechanism via the "profile" key, then combining them would be tricky and
> probably not be done uniformly by different users.
>
> cheers,
>
> dret.
>

Erik: it doesn't appear that we have consensus for adding "profile" to the
list of core GeoJSON members. I haven't seen any signs of extensions that
would be incompatible with your proposal, so we have that going for us. I
look forward to implementing this as an extension and making it a
grassroots best practice.

Martin Daly: I understand your concern about profile URIs mutating from
identifiers into resource URLs that you're obliged to download and parse,
and I've seen the chaos caused by GML's XSDs going offline. You should know
that Erik has similar concerns about the JSON-LD @context URLs: you're
pretty much on the same side from my perspective.

-- 
Sean Gillies

---

From: Martin Thomson <[email-masked]>
Date: Sun, 14 Feb 2016 14:14:22 +1100

On 14 February 2016 at 10:03, Sean Gillies <[email-masked]> wrote:
> list of core GeoJSON members.

Does anyone have any real heartburn about this choice?

I think that the main drawback of this is that if the feature is
valuable to large numbers of GeoJSON, there is a risk of
fragmentation.  On the plus side, GeoJSON is pretty simple and would
remain so.

Note that we'll likely keep this list open in the future as a venue
for coordinating little things like this, which might avoid forking
problems.  Of course that isn't prevention, it's only risk mitigation.

---

From: Stefan Hagen <[email-masked]>
Date: Sun, 14 Feb 2016 09:31:00 +0100

No heartburn here.
Mobiletoppostingly,
Stefan.

> Am 14.02.2016 um 04:14 schrieb Martin Thomson <[email-masked]>:
> 
> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson

---

From: Erik Wilde <[email-masked]>
Date: Sun, 14 Feb 2016 09:45:42 +0100

hello sean.

On 2016-02-14 00:03, Sean Gillies wrote:
> Erik: it doesn't appear that we have consensus for adding "profile" to
> the list of core GeoJSON members. I haven't seen any signs of extensions
> that would be incompatible with your proposal, so we have that going for
> us. I look forward to implementing this as an extension and making it a

as much as i think profiles would be good, it seems to me that there is 
little enthusiasm, so my inclination is to close #97 without action.

i am not sure how to best do this, but if #97 gets implemented as a 
grassroots practice, then we should try to make sure it gets implemented 
as a list/set of URIs, so that it's used robustly enough for GeoJSON to 
follow more than one profile.

> identifiers into resource URLs that you're obliged to download and
> parse, and I've seen the chaos caused by GML's XSDs going offline. You
> should know that Erik has similar concerns about the JSON-LD @context
> URLs: you're pretty much on the same side from my perspective.

i still don't understand martin's concerns about #97. and like you say, 
i definitely share his concerns for the future he is describing, but i 
just don't see how #97 leads towards it. but i have been unsuccessful to 
better explain why #97 and those fears are unrelated. and given the fact 
that nobody really backs #97, i am going to close it.

what we lose by this, and even if there's a best practice emerging using 
a top-level profile member, is the ability to identify profiles on the 
HTTP level through a profile media type parameter. if profiles take over 
the GeoJSON universe, a later revision of the RFC could add that 
parameter without breaking anything.

cheers,

dret.