Skip to content

Update Requirement 2 to account for version increments #255

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jyutzler opened this issue Oct 5, 2016 · 3 comments
Closed

Update Requirement 2 to account for version increments #255

jyutzler opened this issue Oct 5, 2016 · 3 comments
Milestone

Comments

@jyutzler
Copy link
Contributor

jyutzler commented Oct 5, 2016

Right now requirement 2 specifies an exact string for the version but the spec is supposed to be reverse compatible so that, for example, a version 1.2 GeoPackage operates as designed on a 1.0.1-based client. Strict adherence to this requirement makes this impossible. We need to rewrite the requirement so that it accounts for version increments.

@bosborn
Copy link
Contributor

bosborn commented Oct 5, 2016

This is good in theory but there have been some fairly significant changes along the way. I support handling previous versions as much as possible, but some changes are not worth the code maintenance. Would like to avoid an overly complex implementation to handle previous versions of an early adopted specification.

The optional definition_12_063 column (previously definition_12_163) of the gpkg_spatial_ref_sys table is a good example. A GeoPackage SQL implementation abstraction (such as ORM) must handle when this column does and does not exist. While not overly difficult, it is not trivial and adds to the implementation complexity.

Was version 1.2 officially released on 2016-09-28 as indicated by the current specification or is it still in the works? See pull #252 to bump the version number.

@jyutzler
Copy link
Contributor Author

jyutzler commented Oct 5, 2016

What we need is for things not to hard-fail when the version number doesn't match exactly. We do not expect implementers to support all previous versions (it kind of defeats the purpose of spec maintenance) but we want to allow an organization to choose to do so (for example, implement everything in 1.2 but still be able to pass a 1.0.1 compliance test. I have not proposed a specific change yet - I want to get more feedback on what would be an improvement or if this is even needed.

1.2 is not adopted yet but we are nearing the end of what might be considered a beta period. When I am all the way done preparing the release (including release notes and change log), it will be submitted to OGC so that a 30-day review can be started. I hope to complete all of this by New Year's.

@jyutzler
Copy link
Contributor Author

jyutzler commented Oct 18, 2016

GeoPackage is an encoding standard. In other words, it does not impose requirements on clients, merely describes what is allowed in a GeoPackage and what everything means. The way to deal with this issue is to note in prose (outside of a requirement statement) that new versions of GeoPackage are possible and that an application should not fail if it does not see an exact string (e.g., GP11) in that place.

We need to update the abstract test /base/core/container/data/file_format/application_id as well.

Meanwhile we have already been talking to the people responsible for the CITE tests to make sure that those tests don't fail when they see an unexpected value there.

jyutzler added a commit to jyutzler/geopackage that referenced this issue Oct 18, 2016
@jyutzler jyutzler mentioned this issue Oct 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants