Relax Requirement #4

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 (<<features>>, <<tiles>>, and <<attributes>>). Extended GeoPackages MAY contain additional data elements and SQL constructs as specified through the <<extension_mechanism>>.
+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 (<<features>>, <<tiles>>, and <<attributes>>).
 
-* Designing in a way that anticipates the presence of unexpected extensions, e.g., gracefully handling unexpected columns, values, or encodings.
-* Using the <<extension_rtree>> extension for GeoPackages containing a non-trivial amount of vector data.
-* Using the <<extension_crs_wkt>> 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 <<extension_mechanism>>.
+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_rtree>> extension for GeoPackages containing a non-trivial amount of vector data, and
+* the <<extension_crs_wkt>> 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=""]

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+

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].

spec/core/release_notes/1.4.0/clause-4-change-log.adoc

@@ -50,4 +50,10 @@ See <<Clause_Critical>> 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#
 |=======================================================================

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.