Changing a
specification is disruptive because software developers have to make
changes and systems need to be retested to ensure that everything still
works as intended. Some organizations do not have the budget or schedule
flexibility to do this sort of thing properly and in a timely manner. With this in
mind, substantive changes to the core are to be avoided whenever
possible. If it is up to me, there will be no 2.0 release of GeoPackage and I hope to
avoid a 1.1 release (and certainly a 1.3 release) as well.
Like it or not, standards do need to be maintained. The GeoPackage Standards Working Group (SWG) uses the corrigenda[1] process to make corrections to the standard. We continue to review and inspect it to ensure that it is as clear as possible. We do as much as possible in public, using GitHub Issue Tracker to manage issues and relying on public feedback. For each issue, we review the passages in question, come to consensus on their intent, and rewrite them as needed.
A few months ago, we released a corrigendum that focused on the features portion of the standard. We are in the process of producing a second corrigendum that will focus on tiles[2]. We believe this second corrigendum will further improve the readability of the standard and reduce the risk of misinterpretation. While the formal PDF document is not ready yet, the changes that we have already agreed upon are reflected in the on-line specification.
[1] In printed works, a corrigendum is an insert listing errors and corrections. In the web-based world, that is a bit of an anachronism but at a minimum we need a way to fix errors, make clarifications, and show what has been updated.
[2] The GeoPackage Plugfest was an important part of this process because it identified parts of the standard that were not interpreted consistently.
No comments:
Post a Comment