(No) Version

[dirkx]

While I would hate to 'add' a version number to the JSON; I would not mind stating in the RFC that this is version X; and that a certain key/param pair is kept reserved for future version numbers and/or extensions. Just so you do not dig your self into a hole or make things like mimetypes of accept: http negotiation complex.

Likewise; in some other standards; right out of the gate declaring that any key or header starting with 'X-' is experimental and can always be safely ignored is also goodness.

[sthagen]

If and only if we introduce a version concept into the payload (not only the prose of the RFC), then we should discuss IMO and in the same thread about minimal and "current" versions allowing more future proof consume of GeoJSON data. "Breaking" changes would in my understanding result in a new RFC obsoleting the former versions' one. In that case simple semantic version concepts with the suggested "bracketing" addressing a three region concept of either c_version < min_version, or min_version <= c_version < p_version or p_version <= c_version (with p_version seen as being producers (i.e. inside the data) ) and c_version of the consumer, the latter treated as "variable" in that evaluation.

[sgillies]

Taken to the list: https://mailarchive.ietf.org/arch/msg/geojson/YZ_9iBq4sVzsBwx_fq-vHJwnKPc.

[dret]

i have to admit that i dislike the 'X-' part. for reference, there's a whole RFC on discouraging that pattern: https://tools.ietf.org/html/rfc6648
the key question is: what's the difference between a 'X-' thing that can be "safely ignored", and something else i don't know about? can't i "safely ignore" such a non-'X-' thing? my preferred extension model would be to say that any extension can be ignored, and MUST be designed to be ignorable. applications MUST NOT add data that breaks GeoJSON when it is ignored.

[dirkx]

On 12 Jan 2016, at 02:47, Erik Wilde notifications@github.com wrote:

i have to admit that i dislike the 'X-' part. for reference, there's a whole RFC on discouraging that pattern: https://tools.ietf.org/html/rfc6648
the key question is: what's the difference between a 'X-' thing that can be "safely ignored", and something else i don't know about? can't i "safely ignore" such a non-'X-' thing? my preferred extension model would be to say that any extension can be ignored, and MUST be designed to be ignorable. applications MUST NOT add data that breaks GeoJSON when it is ignored.

I totally see the point of RFC 6648 its crusade against ‘X-‘. And would fully support going down that route.

However RFC 6648 is not ‘free’ — section 4 says in effect that one ‘SHOULD establish registries…’ etc (or in our case - in effect rely even more on the various OGC well known identifiers).

In any case - stating up front that ‘Version’ is the field used once there are multiple versions* and that this is version ‘1.00’ and that one can assume a value of ‘version’ set to the string ‘1’ or something - is useful. Or alternatively state that such field shoud not occur in implementations of this version of the spec.

Dw

*: and leaving the meaning of . with respect to backward compatibility open.

[sgillies]

@dirkx @dret @sdrees do you have any comments on 3be524c?

[dirkx]

On 24 Jan 2016, at 06:49, Sean Gillies notifications@github.com wrote:

@dirkx @dret @sdrees do you have any comments on 3be524c?

I think this is a bit overly optimistic. Version is usually a lot more complex.

I would at the very least say either

a) The member “version” MUST be present and contain the value “1.0” for this version of the specification.

or

b) The member “version” and SHOULD be present. If it is not present then the value ‘1.0’ MUST be assumed.

potentially with some verbiage on the meaning of the version value (e.g. following the usual industry standard approach of major/minor; with major versions breaking compatibility and minor version being strictly backwards compatible; e.g. https://apr.apache.org/versioning.html).

As that helps implementors not make things (too) brittle.

Dw.

[dret]

On 2016-01-25 2:10 , Dirk-Willem van Gulik wrote:

On 24 Jan 2016, at 06:49, Sean Gillies notifications@github.com wrote:
@dirkx @dret @sdrees do you have any comments on 3be524c?
I think this is a bit overly optimistic. Version is usually a lot more
complex.
I would at the very least say either
a) The member “version” MUST be present and contain the value “1.0” for
this version of the specification.
or
b) The member “version” and SHOULD be present. If it is not present then
the value ‘1.0’ MUST be assumed.
potentially with some verbiage on the meaning of the version value (e.g.
following the usual industry standard approach of major/minor; with
major versions breaking compatibility and minor version being strictly
backwards compatible; e.g. https://apr.apache.org/versioning.html).
As that helps implementors not make things (too) brittle.

i think that's pretty much exactly what i tried to say. i tend to think
that putting required values into defaulted attributes also is a rather
brittle pattern.

what if spec v2 changes that to say "MUST be assumed to be 2.0", and
then implementations have to somehow sniff if a document with no version
is actually 1.0 or 2.0? some implementations always will go that route,
but we shouldn't force that onto all.

if anything (and i am against the version thing anyway, but assuming
that's what the group wants to do), we maybe could say (given that there
is a ton of versionless GeoJSON out there):

• version MUST be present and say "1.0" for this version of the spec.
• implementations seeing GeoJSON with no "version" MUST assume the
  version member to be present and say "1.0".

[dirkx]

On 25 Jan 2016, at 18:54, Erik Wilde notifications@github.com wrote:

On 2016-01-25 2:10 , Dirk-Willem van Gulik wrote:

On 24 Jan 2016, at 06:49, Sean Gillies notifications@github.com wrote:
@dirkx @dret @sdrees do you have any comments on 3be524c?
I think this is a bit overly optimistic. Version is usually a lot more
complex.
I would at the very least say either
a) The member “version” MUST be present and contain the value “1.0” for
this version of the specification.
or
b) The member “version” and SHOULD be present. If it is not present then
the value ‘1.0’ MUST be assumed.
potentially with some verbiage on the meaning of the version value (e.g.
following the usual industry standard approach of major/minor; with
major versions breaking compatibility and minor version being strictly
backwards compatible; e.g. https://apr.apache.org/versioning.html).
As that helps implementors not make things (too) brittle.

i think that's pretty much exactly what i tried to say. i tend to think
that putting required values into defaulted attributes also is a rather
brittle pattern.

what if spec v2 changes that to say "MUST be assumed to be 2.0", and
then implementations have to somehow sniff if a document with no version
is actually 1.0 or 2.0? some implementations always will go that route,
but we shouldn't force that onto all.

Right - so this is why it is not bad practise to catch this early; and use a should/must combination to make clear that such a document is version 1.00 - and that if it is not - the fault is ‘at the other side’.

Not doing so makes the ecosystem itself brittle -OR- causes the most powerful party to lay down the law for all others. Meaning that as an implementor you get crushed between the powerful parties and your customer :)

• version MUST be present and say "1.0" for this version of the spec.
• implementations seeing GeoJSON with no "version" MUST assume the
  version member to be present and say "1.0”.

That is indeed a very safe stance.

Dw.

[martinthomson]

Folks, would you mind taking this discussion to geojson@ietf.org ? It looks like some people are having trouble following the discussion across the two venues.