From 50d94cf88372cdf2e48b211a5844916c9db69ee1 Mon Sep 17 00:00:00 2001 From: Jeff Yutzler Date: Wed, 29 Mar 2023 20:42:20 -0400 Subject: [PATCH] Relax Requirement #4 --- spec/core/1_base.adoc | 20 ++++++++++++++----- spec/core/annexes/ats.adoc | 16 --------------- .../release_notes/1.4.0/annex-history.adoc | 1 + .../1.4.0/clause-4-change-log.adoc | 6 ++++++ .../1.4.0/clause-6-substantive.adoc | 9 +++++++++ 5 files changed, 31 insertions(+), 21 deletions(-) diff --git a/spec/core/1_base.adoc b/spec/core/1_base.adoc index c594cd89..a225d180 100644 --- a/spec/core/1_base.adoc +++ b/spec/core/1_base.adoc @@ -81,14 +81,24 @@ Previous statements that the media type is [line-through]#`application/geopackag [caption=""] .Requirement 4 ==== -A GeoPackage SHALL only contain the data elements (tables, columns, or values) and SQL constructs (views, constraints, or triggers) specified in the core of this encoding standard (<>, <>, and <>). Extended GeoPackages MAY contain additional data elements and SQL constructs as specified through the <>. +A GeoPackage SHALL [line-through]#only# contain the data elements (tables, columns, or values) and SQL constructs (views, constraints, or triggers) specified in the core of this encoding standard. ==== -The *GeoPackage* designation is designed to provide maximum interoperability between applications. In an *Extended GeoPackage*, the extension mechanism is used to provide additional capabilities in a way that maintains interoperability as much as possible. Developers are encouraged to consider the implications of extensions when designing their applications. Best practices include the following: +A *GeoPackage* is expected to have content in at least one of the core options (<>, <>, and <>). -* Designing in a way that anticipates the presence of unexpected extensions, e.g., gracefully handling unexpected columns, values, or encodings. -* Using the <> extension for GeoPackages containing a non-trivial amount of vector data. -* Using the <> extension, which is strongly recommended due to inherent weaknesses in the original standard for encoding coordinate reference systems. +*Extended GeoPackages* MAY contain additional data elements and SQL constructs as specified through the <>. +In an Extended GeoPackage, the extension mechanism is used to provide additional capabilities in a way that maintains interoperability as much as possible. Developers are encouraged to consider the implications of extensions when designing their applications. Best practices include the following designing extensions in a way that anticipates the presence of unexpected extensions, e.g., gracefully handling unexpected columns, values, or encodings. + +[NOTE] +==== +The *GeoPackage* designation was originally designed to indicate a schema with maximum interoperability. +However, as the standard has evolved, it has become increasingly important for GeoPackages to contain certain extensions such as the following: + +* the <> extension for GeoPackages containing a non-trivial amount of vector data, and +* the <> extension, which is strongly recommended due to inherent weaknesses in the original standard for encoding coordinate reference systems. + +In light of this evolution, the difference between a GeoPackage and an Extended GeoPackage is no longer relevant. +==== [[r5]] [caption=""] diff --git a/spec/core/annexes/ats.adoc b/spec/core/annexes/ats.adoc index e8d868c1..5c2e097c 100644 --- a/spec/core/annexes/ats.adoc +++ b/spec/core/annexes/ats.adoc @@ -51,22 +51,6 @@ *File Contents* -[cols="1,5a"] -|======================================== -|*Test Case ID* |+/base/core/container/data/file_contents+ -|*Test Purpose* |Verify that the GeoPackage only contains specified contents -|*Test Method* -| . SELECT COUNT(*) from gpkg_extensions; -. Not testable if table exists and count > 0 -. For each gpkg_* table_name -.. PRAGMA table_info(table_name) -.. Continue if returns an empty result set -.. Fail if column definitions returned by "PRAGMA table_info" do not match column definitions for the table in Annex C. -. Pass if no fails -|*Reference* |Clause 1.1.1.1.3 Req 4: -|*Test Type* |Basic -|======================================== - [cols="1,5a"] |======================================== |*Test Case ID* |+/base/core/container/data/table_data_types+ diff --git a/spec/core/release_notes/1.4.0/annex-history.adoc b/spec/core/release_notes/1.4.0/annex-history.adoc index 56a06020..c532276b 100644 --- a/spec/core/release_notes/1.4.0/annex-history.adoc +++ b/spec/core/release_notes/1.4.0/annex-history.adoc @@ -6,6 +6,7 @@ |==================== |Date |Release |Editor | Primary clauses modified |Descriptions |2023-03-19 |0.1 |J. Yutzler | all| Initial Revision +|2023-03-29 |0.2 |J. Yutzler | 4, 6| 640/655 |==================== For the complete revision history, see link:https://github.com/opengeospatial/geopackage/commits/master/spec/core/release_notes/1.4.0[the GitHub repository]. diff --git a/spec/core/release_notes/1.4.0/clause-4-change-log.adoc b/spec/core/release_notes/1.4.0/clause-4-change-log.adoc index 0648680e..d6b4a21f 100644 --- a/spec/core/release_notes/1.4.0/clause-4-change-log.adoc +++ b/spec/core/release_notes/1.4.0/clause-4-change-log.adoc @@ -50,4 +50,10 @@ See <> for more information on critical changes and |[yellow-background]#Make DATETIME format more flexible# |[yellow-background]#Correctness# |link:https://github.com/opengeospatial/geopackage/issues/640[#640] |link:https://github.com/opengeospatial/geopackage/pull/655[#655] | A | 1.1.1.1.1 | Move example indicating GeoPackage Version format to a note | Clarity +|[yellow-background]#link:https://github.com/opengeospatial/geopackage/issues/629[#629]# +|[yellow-background]#link:https://github.com/opengeospatial/geopackage/pull/656[#656]# +|[yellow-background]#S# +|[yellow-background]#1.1.1.1.3# +|[yellow-background]#Relax Requirement #4# +|[yellow-background]#Usability# |======================================================================= diff --git a/spec/core/release_notes/1.4.0/clause-6-substantive.adoc b/spec/core/release_notes/1.4.0/clause-6-substantive.adoc index a7bd7d31..26f6ada1 100644 --- a/spec/core/release_notes/1.4.0/clause-6-substantive.adoc +++ b/spec/core/release_notes/1.4.0/clause-6-substantive.adoc @@ -10,3 +10,12 @@ This is unnecessarily restrictive and can cause problems in the following ways: In fact, https://sqlite.org/lang_datefunc.html#time_values[SQLite documentation] offers a number of legal formats and allows fractional seconds to have fewer or more than three digits. In response, the SWG agreed to relax the definition, while retaining compatibility with ISO-8601. + +=== Relax Requirement #4 +The *GeoPackage* designation was originally designed to indicate a schema with maximum interoperability. +However, as the standard has evolved, it has become increasingly important for GeoPackages to contain certain extensions. +In light of this evolution, the difference between a GeoPackage and an Extended GeoPackage is no longer relevant. +If anything, this requirement was just causing confusion. +The presence of extensions would cause the Executable Test Suite (ETS) to skip Requirement 4, which has implications in how ETS results are interpreted. + +This change has no significant operational impact.