Upgrade the specification from ISO 19103:2015 to ISO 19103:2024.

This is incomplete, the following tasks still need to be done:

* Review the UML schemas
* Verify the Metanorma rendered pages, including reference in bibliography
* Review section on `Record` (removed from ISO 19103 but still used in GeoAPI).
* Review section on `GenericName` (removed from ISO 19103 but still used in GeoAPI).
* Review section on `InternationalString` for replacing the standard source by `PT_FreeText`.

#102

src/main/metanorma/code/java/JNDI.adoc

@@ -1,21 +1,21 @@
 [[JNDI]]
 ==== Names in JNDI context
 
-The ISO 19103 name types (<<generic_name>>) define mapping methods from a name to the object identified by that name.
-But the mapping methods defined by ISO 19103 are not part of the `Name­Space` interface defined by GeoAPI.
+The ISO 19103:2015 name types (<<generic_name>>) define mapping methods from a name to the object identified by that name.
+But the mapping methods defined by ISO 19103:2015 are not part of the `Name­Space` interface defined by GeoAPI.
 Instead, GeoAPI leaves that functionality to frameworks such as the Java Naming and Directory Interface™ (JNDI).
 Java applications which need such mapping may use the methods in the `javax​.naming​.Context` interface:
 
 .Java Naming and Directory Interface equivalences
 [.compact, options="header"]
-|====================================================================================
-|ISO 19103 `NameSpace` member   |`org.opengis.util.NameSpace` |`javax.naming.Context`
-|`isGlobal`                     |`isGlobal()`                 |
-|`acceptableClassList`          |                             |
-|`generateID(Any)`              |                             |
-|`locate(LocalName)`            |                             |`lookup(Name)`
-|`name`                         |`name()`                     |`getNameInNamespace()`
-|`registerID(LocalName, Any)`   |                             |`bind(Name, Object)`
-|`select(GenericName)`          |                             |`lookup(Name)`
-|`unregisterID(LocalName, Any)` |                             |`unbind(Name)`
-|====================================================================================
+|=======================================================================================
+|ISO 19103:2015 `NameSpace` member |`org.opengis.util.NameSpace` |`javax.naming.Context`
+|`isGlobal`                        |`isGlobal()`                 |
+|`acceptableClassList`             |                             |
+|`generateID(Any)`                 |                             |
+|`locate(LocalName)`               |                             |`lookup(Name)`
+|`name`                            |`name()`                     |`getNameInNamespace()`
+|`registerID(LocalName, Any)`      |                             |`bind(Name, Object)`
+|`select(GenericName)`             |                             |`lookup(Name)`
+|`unregisterID(LocalName, Any)`    |                             |`unbind(Name)`
+|=======================================================================================

src/main/metanorma/sections/clause_3_references.adoc

@@ -12,7 +12,7 @@
 
 * [[[ISO19101-2,ISO 19101-2:2018]]], _Geographic information — Reference model — Part 2: Imagery_
 
-* [[[ISO19103,ISO 19103:2015]]], _Geographic information — Conceptual schema language_
+* [[[ISO19103,ISO 19103:2024]]], _Geographic information — Conceptual schema language_
 
 * [[[ISO19107,ISO 19107:2003]]], _Geographic information — Spatial schema_
 

src/main/metanorma/sections/clause_4_terms_and_definitions.adoc

@@ -9,12 +9,12 @@ and implementation code which provides the API
 
 [[term_cardinality]]
 === cardinality
-number of elements in a set
+number of values
 
 [.source]
 <<ISO19103>>
 
-NOTE: Contrast with _multiplicity_, which is the range of possible cardinalities a set can hold.
+NOTE: Cardinality is a characteristic of a collection.
 
 
 [[term_conceptual_model]]
@@ -28,7 +28,7 @@ model that defines concepts of a universe of discourse
 [[term_constraint]]
 === constraint
 UML condition or restriction expressed in natural language text or in a machine readable language
-for the purpose of declaring some of the semantics of an element
+for the purpose of declaring some of the semantics of an element or set of elements
 
 [.source]
 <<ISO19103>>
@@ -93,15 +93,17 @@ identifiable collection of data
 
 [[term_datatype]]
 === datatype
-specification of a value domain with operations allowed on values in this domain
+set of distinct values, characterized by properties of those values, and by operations on those values
 
 [.source]
 <<ISO19103>>
 
-NOTE: Data types include primitive predefined types and user definable types.
+NOTE: Properties of data type values are ordered or unordered, exact or approximate,
+numeric or non-numeric and, if ordered, bounded or unbounded, as described in ISO/IEC 11404.
 
 [example]
-`Integer`, `Real`, `Boolean`, `String` and `Date`.
+The data type `Boolean` with properties `unordered`, `exact` and `non-numeric`,
+and with operations `equal`, `not`, `and` and `or`.
 
 
 [[term_dynamic_attribute]]
@@ -112,6 +114,14 @@ characteristic of a feature in which its value taken from the domain of the feat
 <<OGC19-045>>
 
 
+[[term_enumeration]]
+=== enumeration
+data type whose values are named individually in the model
+
+[.source]
+<<ISO19103>>
+
+
 [[term_feature]]
 === feature
 abstraction of a real world phenomena
@@ -166,12 +176,39 @@ spatial object representing a geometric set
 <<ISO19107>>
 
 
+[[term_identifier]]
+=== identifier
+linguistically independent sequence of characters capable of uniquely and permanently
+identifying that with which it is associated
+
+[.source]
+<<ISO19103>>
+
+
+[[term_inheritance]]
+=== inheritance
+mechanism by which more specific entities incorporate structure and behavior defined by more general entities
+
+[.source]
+<<ISO19103>>
+
+
+[[term_instance]]
+=== instance
+individual entity
+
+[.source]
+<<ISO19103>>
+
+
 [[term_interface]]
 === interface
 UML classifier that represents a declaration of a set of coherent public UML features and obligations
+that together constitute a coherent service
 
-NOTE: An interface specifies a contract; any classifier that realizes the interface must fulfil that contract.
-The obligations that can be associated with an interface are in the form of various kinds of constraints
+NOTE: An interface specifies a contract;
+UML requires that any _instance_ (<<term_instance>>) of a classifier that realizes the interface fulfills that contract.
+The obligations associated with an interface are in the form of _constraints_ (<<term_constraint>>)
 (such as pre- and post-conditions) or protocol specifications,
 which can impose ordering restrictions on interactions through the interface.
 
@@ -213,17 +250,44 @@ reference system (ISO 19111), also called a local frame or a local Euclidean coo
 
 [[term_multiplicity]]
 === multiplicity
-UML specification of the range of allowable cardinalities that a set may assume
+UML specification of the valid _cardinalities_ (<<term_cardinality>>)
+
+[.source]
+<<ISO19103>>
+
+NOTE: An _instance_ (<<term_instance>>) of a collection specified as having a multiplicity of "1…3"
+has at least one value and has not more than three values.
+
+
+[[term_namespace]]
+=== namespace
+named element that either owns or imports, or both, a set of named elements that can be identified by name
 
 [.source]
 <<ISO19103>>
 
-NOTE: Contrast with _cardinality_, which is the number of elements in a set.
+
+[[term_object]]
+=== object
+individual with a state and relationship to other individuals
+
+[.source]
+<<ISO19103>>
+
+NOTE: An object is an _instance_ (<<term_instance>>) of a class.
 
 
 [[term_package]]
 === package
-UML general purpose mechanism for organizing elements into groups
+element that is used to group elements, and provides a _namespace_ (<<term_namespace>>) for the grouped elements
+
+[.source]
+<<ISO19103>>
+
+
+[[term_primitive_type]]
+=== primitive type
+predefined _data type_ (<<term_datatype>>) without any substructure
 
 [.source]
 <<ISO19103>>
@@ -244,16 +308,12 @@ an interpreted high-level programming language for general-purpose programming
 
 [[term_realization]]
 === realization
-specialized abstraction relationship between two sets of model elements, one representing
-a specification (the supplier) and the other representing an implementation of the latter (the client)
+abstraction between two named elements or sets of named elements,
+one representing a specification and the other representing an implementation of the latter
 
 [.source]
 <<ISO19103>>
 
-NOTE: Realization indicates inheritance of behaviour without inheritance of structure.
-
-NOTE: GeoAPI and GML are two realizations of OGC/ISO abstract specifications.
-
 
 [[term_trajectory]]
 === trajectory

src/main/metanorma/sections/clause_5_conventions.adoc

@@ -57,6 +57,7 @@ OGC::  Open Geospatial Consortium
 UML::  Unified Modeling Language
 URI::  Uniform Resource Identifiers
 UTC::  Coordinated Universal Time
+UUID:: Universally Unique Identifier
 WKT::  Well Known Text
 WMS::  Web Map Service
 XML::  Extensible Markup Language

src/main/metanorma/sections/informative/collections.adoc

@@ -1,25 +1,27 @@
 [[collections]]
 ==== Collections
-_From <<ISO19103>> §7.3_
+_From <<ISO19103>> §7.3.2.3_
 
-GeoAPI implements ISO 19103 collection interfaces using the standard Collections Frameworks provided by {supported-languages}.
-A `Set` is a finite collection of objects where each object appears only once.
-A `Bag` is similar to a `Set` except that it may contain duplicated instances.
-The order of elements in a `Set` or a `Bag` is not specified.
-A `Sequence` is similar to a `Bag` except that elements are ordered.
+GeoAPI implements multi-valued properties using the standard Collections Frameworks provided by {supported-languages}.
+If the property has the `isUnique` meta-property, then the collection is a `Set`:
+a finite collection of objects where each object appears only once in unspecified order.
+If the property has the `isOrdered` meta-property, then the collection is a `Sequence`:
+a collection of object where elements are ordered and may appear many times.
 
 .Collections mapping
 [options="header"]
-|========================================================
-|ISO 19103 interface |Java type              |Python type
-|`Collection`        |`java.util.Collection` |`Sequence`
-|`Bag`               |`java.util.Collection` |`Sequence`
-|`Set`               |`java.util.Set`        |`Set`
-|`Sequence`          |`java.util.List`       |`Sequence`
-|`Dictionary`        |`java.util.Map`        |`dict`
-|========================================================
+|===============================================================
+|Meta-property |ISO 19103:2015     |Java type       |Python type
+|`isUnique`    |`Set`        ^(1)^ |`java.util.Set` |`Set`
+|`isOrdered`   |`Sequence`   ^(1)^ |`java.util.List`|`Sequence`
+|              |`Dictionary`       |`java.util.Map` |`dict`
+|===============================================================
+
+Notes:
+
+* (1) Deprecated in ISO 19103:2024, but listed because still present in some standards.
 
 Unless otherwise required by the semantic of a property, GeoAPI prefers to use the `Collection` type in Java method signatures.
-This allows implementers to choose their preferred subtypes, usually `Set` or `Sequence`.
+This allows implementers to choose their preferred subtypes, usually `Set` or `List`.
 The `Set` type is not the default type because enforcing element uniqueness may constrain implementations to use hash tables
 or similar algorithms, which is not always practical.

src/main/metanorma/sections/informative/primitives.adoc → src/main/metanorma/sections/informative/common_types.adoc

@@ -1,8 +1,8 @@
-[[primitives]]
-==== Primitive types
-_From <<ISO19103>> §7.2.1 and 7.2.5 to 7.2.11_
+[[common_types]]
+==== Common types
+_From <<ISO19103>> §8.2_
 
-Each primitive type of the OGC/ISO specifications maps to zero, one or two object structures in GeoAPI.
+Each core type of the OGC/ISO specifications maps to zero, one or two object structures in GeoAPI.
 Where the mapping can be made directly to a programming language primitive type, such as `int` and `float`,
 the language primitive is preferred. In languages where "primitives" and "wrappers" are distinct,
 wrappers may be used instead of primitives on a case-by-case basis.
@@ -18,11 +18,9 @@ The following table shows the mapping used by GeoAPI to represent the primitive
 |`Real`                 |`double`                         ^(1)^ |`float`
 |`Decimal` ^(3)^        |`java.math.BigDecimal`                 |`float`
 |`Vector`               |unimplemented                          |unimplemented
-|`Sequence<Character>`  |`java.lang.CharSequence`               |`str`
 |`CharacterString`      |`java.lang.String`               ^(4)^ |`str`
-|`LanguageString` ^(5)^ |`org.opengis.util.InternationalString` |`str`
-|`LanguageCode`   ^(5)^ |`java.util.Locale`                     |
-|`CharacterSetCode`     |`java.nio.charset.Charset`             |
+|`URI`                  |`java.net.URI`                         |
+|`UUID`                 |`java.util.UUID`                       |
 |================================================================================
 
 Notes:
@@ -31,4 +29,3 @@ Notes:
 * (2) Sometimes substituted by `long` or `java​.lang​.Long` where the value may exceed 2³².
 * (3) `Decimal` differs from `Real`, as `Decimal` is exact in base 10 while `Real` may not.
 * (4) Substituted by `org​.opengis​.util​.International­String` where the string representation depends on the locale.
-* (5) Actually an _extension data type_ defined in <<ISO19103>> annex C.2. See _internationalization_ in <<internationalization>>.

src/main/metanorma/sections/informative/controlled_vocabulary.adoc

@@ -1,6 +1,6 @@
 [[controlled_vocabulary]]
 ==== Controlled vocabulary
-_From <<ISO19103>> §6.5_
+_From <<ISO19103>> §7.2.4 and §7.8_
 
 A controlled vocabulary is an established list of standardized terminology
 (names, words or phrases) with associated definitions for use to identify,
@@ -19,21 +19,19 @@ For the open case, GeoAPI defines the `Code­List` abstract class in Java.
 .Enumerated types mapping
 [options="header"]
 |===========================================================
-|ISO 19103 type |Java type                   |Python type
-|CodeList       |`org.opengis.util.CodeList` |`Enum`  ^(1)^
-|Enumeration    |`java.lang.Enum`            |`Enum`
-|`Bit`          |unimplemented               |unimplemented
-|`Digit`        |unimplemented               |unimplemented
-|`Sign`         |unimplemented               |unimplemented
+|ISO 19103 type   |Java type                   |Python type
+|`CodeList` ^(1)^ |`org.opengis.util.CodeList` |`Enum` ^(2)^
+|`GI_Enumeration` |`java.lang.Enum`            |`Enum`
 |===========================================================
 
 Notes:
 
-- (1) GeoAPI does not yet provide an extensible implementation of code list in the Python language,
+- (1) `CodeList` has been deprecated in ISO 19103:2024, replaced by `CodeSet`.
+  GeoAPI has no equivalent structure yet.
+- (2) GeoAPI does not yet provide an extensible implementation of code list in the Python language,
   but this limitation may be addressed in a future version.
 
 Code lists can be extended by calls to `valueOf(String)` methods in the Java language.
-Extensions should follow ISO 19103 recommendation:
 Extensions of a code list use the existing code list values and merely add additional unique values.
 These additional values should not replace an existing code by changing the name or definition,
 or have the same definition as an existing value.

src/main/metanorma/sections/informative/core_types.adoc

@@ -3,8 +3,7 @@
 
 The ISO 19103 specification (_Geographic Information – Conceptual schema language_) defines types
 which are used as building blocks by the other standards in the 19100 series.
-<<ISO19103>> defines Primitive types (§7.2 of that standard), Collection types (§7.3), Enumerated types (§7.4),
-Name types (§7.5), Record types (§7.7) and Unit of Measure types (§C.4).
+<<ISO19103>> defines code data types such as real numbers, dates and times.
 GeoAPI maps these types either to existing types from the {supported-languages} standard libraries or, when needed,
 to types defined in the `opengis​.util` package.
 That utility package is used by GeoAPI for types defined in the ISO 19103 specification
@@ -17,7 +16,7 @@ since they have not yet appeared in any other specification for which GeoAPI def
 Such types are listed as "unimplemented" in the tables below.
 
 
-include::primitives.adoc[]
+include::common_types.adoc[]
 
 include::datetime.adoc[]
 
@@ -29,8 +28,6 @@ include::generic_name.adoc[]
 
 include::records.adoc[]
 
-include::web_types.adoc[]
-
 include::internationalization.adoc[]
 
 include::units.adoc[]

src/main/metanorma/sections/informative/datetime.adoc

@@ -1,6 +1,6 @@
 [[datetime]]
 ==== Date and time
-_From <<ISO19103>> §7.2.2 to 7.2.4_
+_From <<ISO19103>> §8.2_
 
 The ISO 19103 `Date` interface gives values for year, month and day
 while the `Time` interface gives values for hour, minute and second.
@@ -14,13 +14,18 @@ The timezone information is often desired for geospatial data
 (for example, in the acquisition time of a remote sensing image),
 but may be undesired for some other cases like office opening hours
 (for example, if they apply to all offices spanning the multiple timezones of a country).
-GeoAPI generally uses a more flexible type than the one mandated by ISO specifications
+
+`PositionInTime` is the parent interface of all other ISO 19103 interfaces listed in the table below.
+GeoAPI generally uses that parent interface instead of more specific types mandated in ISO specifications
 for letting developers choose how they want to handle timezones.
 
 .Date and time types suggested mapping
 [options="header"]
 |==================================================================================
-|ISO 19103 interface   |Suggested Java class                  |Python type
+|ISO 19103 interface   |Suggested Java type                   |Python type
+|`PositionInTime`      |`java.time.temporal.Temporal`         |
+|`Year`                |`java.time.Year`          ^(1)^       |
+|`YearMonth`           |`java.time.YearMonth`     ^(1)^       |
 |`Date`                |`java.time.LocalDate`     ^(1)^ ^(2)^ |`datetime.date`
 |`Time`                |`java.time.OffsetTime`    ^(1)^       |`datetime.time`
 |`DateTime`            |`java.time.ZonedDateTime` ^(1)^ ^(2)^ |`datetime.datetime`

src/main/metanorma/sections/informative/feature/index.adoc

@@ -4,7 +4,6 @@
 The GeoAPI feature package uses the `opengis​.feature` namespace
 and implements the types defined in the <<ISO19109>> – _Rules for application schema_ specification.
 The main UML materialized by GeoAPI is ISO 19109 figure 5 #(TODO: verify)#.
-That figure is also reproduced in <<ISO19103>> figure E.6.
 
 #TODO: provide UML and explain the mapping.#