diff --git a/src/main/metanorma/code/java/JNDI.adoc b/src/main/metanorma/code/java/JNDI.adoc index 158225d57..e201d2624 100644 --- a/src/main/metanorma/code/java/JNDI.adoc +++ b/src/main/metanorma/code/java/JNDI.adoc @@ -1,21 +1,21 @@ [[JNDI]] ==== Names in JNDI context -The ISO 19103 name types (<>) 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 (<>) 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)` +|======================================================================================= diff --git a/src/main/metanorma/sections/clause_3_references.adoc b/src/main/metanorma/sections/clause_3_references.adoc index 26416e99f..5bd53ecd3 100644 --- a/src/main/metanorma/sections/clause_3_references.adoc +++ b/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_ diff --git a/src/main/metanorma/sections/clause_4_terms_and_definitions.adoc b/src/main/metanorma/sections/clause_4_terms_and_definitions.adoc index a8e1d8cc2..69f3cdb5a 100644 --- a/src/main/metanorma/sections/clause_4_terms_and_definitions.adoc +++ b/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] <> -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] <> @@ -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] <> -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 <> +[[term_enumeration]] +=== enumeration +data type whose values are named individually in the model + +[.source] +<> + + [[term_feature]] === feature abstraction of a real world phenomena @@ -166,12 +176,39 @@ spatial object representing a geometric set <> +[[term_identifier]] +=== identifier +linguistically independent sequence of characters capable of uniquely and permanently +identifying that with which it is associated + +[.source] +<> + + +[[term_inheritance]] +=== inheritance +mechanism by which more specific entities incorporate structure and behavior defined by more general entities + +[.source] +<> + + +[[term_instance]] +=== instance +individual entity + +[.source] +<> + + [[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_ (<>) of a classifier that realizes the interface fulfills that contract. +The obligations associated with an interface are in the form of _constraints_ (<>) (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_ (<>) + +[.source] +<> + +NOTE: An _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] <> -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] +<> + +NOTE: An object is an _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_ (<>) for the grouped elements + +[.source] +<> + + +[[term_primitive_type]] +=== primitive type +predefined _data type_ (<>) without any substructure [.source] <> @@ -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] <> -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 diff --git a/src/main/metanorma/sections/clause_5_conventions.adoc b/src/main/metanorma/sections/clause_5_conventions.adoc index 96216ec7a..74828a620 100644 --- a/src/main/metanorma/sections/clause_5_conventions.adoc +++ b/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 diff --git a/src/main/metanorma/sections/informative/collections.adoc b/src/main/metanorma/sections/informative/collections.adoc index c6bf882a0..69767c7f7 100644 --- a/src/main/metanorma/sections/informative/collections.adoc +++ b/src/main/metanorma/sections/informative/collections.adoc @@ -1,25 +1,27 @@ [[collections]] ==== Collections -_From <> §7.3_ +_From <> §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. diff --git a/src/main/metanorma/sections/informative/primitives.adoc b/src/main/metanorma/sections/informative/common_types.adoc similarity index 73% rename from src/main/metanorma/sections/informative/primitives.adoc rename to src/main/metanorma/sections/informative/common_types.adoc index b183c7399..24ded0465 100644 --- a/src/main/metanorma/sections/informative/primitives.adoc +++ b/src/main/metanorma/sections/informative/common_types.adoc @@ -1,8 +1,8 @@ -[[primitives]] -==== Primitive types -_From <> §7.2.1 and 7.2.5 to 7.2.11_ +[[common_types]] +==== Common types +_From <> §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` |`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 <> annex C.2. See _internationalization_ in <>. diff --git a/src/main/metanorma/sections/informative/controlled_vocabulary.adoc b/src/main/metanorma/sections/informative/controlled_vocabulary.adoc index 9522e3cdc..a90c76f64 100644 --- a/src/main/metanorma/sections/informative/controlled_vocabulary.adoc +++ b/src/main/metanorma/sections/informative/controlled_vocabulary.adoc @@ -1,6 +1,6 @@ [[controlled_vocabulary]] ==== Controlled vocabulary -_From <> §6.5_ +_From <> §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. diff --git a/src/main/metanorma/sections/informative/core_types.adoc b/src/main/metanorma/sections/informative/core_types.adoc index a8f5099f8..a9385c654 100644 --- a/src/main/metanorma/sections/informative/core_types.adoc +++ b/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. -<> 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). +<> 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[] diff --git a/src/main/metanorma/sections/informative/datetime.adoc b/src/main/metanorma/sections/informative/datetime.adoc index f2858751e..37d737165 100644 --- a/src/main/metanorma/sections/informative/datetime.adoc +++ b/src/main/metanorma/sections/informative/datetime.adoc @@ -1,6 +1,6 @@ [[datetime]] ==== Date and time -_From <> §7.2.2 to 7.2.4_ +_From <> §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` diff --git a/src/main/metanorma/sections/informative/feature/index.adoc b/src/main/metanorma/sections/informative/feature/index.adoc index 4878cb05d..49d26d119 100644 --- a/src/main/metanorma/sections/informative/feature/index.adoc +++ b/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 <> – _Rules for application schema_ specification. The main UML materialized by GeoAPI is ISO 19109 figure 5 #(TODO: verify)#. -That figure is also reproduced in <> figure E.6. #TODO: provide UML and explain the mapping.# diff --git a/src/main/metanorma/sections/informative/generic_name.adoc b/src/main/metanorma/sections/informative/generic_name.adoc index 95fadcc40..d12e87d85 100644 --- a/src/main/metanorma/sections/informative/generic_name.adoc +++ b/src/main/metanorma/sections/informative/generic_name.adoc @@ -1,6 +1,13 @@ [[generic_name]] ==== Name types -_From <> §7.5_ +_From ISO 19103:2015 §7.5_ + +[WARNING] +========= +Name data types have been removed from ISO 19103:2024. +But they are still used in GeoAPI 3 for historical reasons. +This section is based on the previous version of the ISO 19103 standard. +========= A `Generic­Name` is a sequence of identifiers rooted within the context of a namespace. `NameSpace` defines a domain in which names can be mapped to objects. @@ -9,7 +16,7 @@ in which case the namespace is materialized by the table. Each storage (XML, shapefiles, netCDF, …) may have their own constraints for names in their namespaces. [[generic_name_UML]] -.Generic names derived from ISO 19103 +.Generic names derived from ISO 19103:2015 image::names.svg[UML of name objects] `GenericName` is the base interface for all names in a `NameSpace`. @@ -32,7 +39,7 @@ These types are mapped to {supported-languages} classes as below: .Name types mapping [options="header"] |========================================================================================= -|ISO 19103 interface |Java interface |Python class +|ISO 19103:2015 type |Java interface |Python class |(constructors) |`org.opengis.util.NameFactory` | |`NameSpace` |`org.opengis.util.NameSpace` |`opengis.metadata.naming.NameSpace` |`GenericName` |`org.opengis.util.GenericName` |`opengis.metadata.naming.GenericName` @@ -93,7 +100,7 @@ as described in the following sub-sections. [[generic_name_departures_for_generalization]] ====== Generalization -GeoAPI extends the ISO 19103 model by adding a (_path_, _tip_) pair in complement to the (_head_, _tail_) pair. +GeoAPI extends the ISO 19103:2015 model by adding a (_path_, _tip_) pair in complement to the (_head_, _tail_) pair. While the _head_ and _tip_ properties carry non-trivial information only inside `Scoped­Name`, GeoAPI nevertheless makes them available from the parent `Generic­Name` interface (not shown in <>) with the restriction that they shall return `this` (Java) or `self` (Python) when the name is an instance of `Local­Name`. @@ -101,7 +108,7 @@ This generalization makes common operations simpler without the need to check fo [[generic_name_departures_as_renaming]] ====== Renaming -The ISO 19103 `Generic­Name.aName` property appears as `toString` in <>, +The ISO 19103:2015 `Generic­Name.aName` property appears as `toString` in <>, but this property should be mapped to the standard mechanism for representing an arbitrary object as a character string in the target programming language. In Java this is the `toString()` method; @@ -111,7 +118,7 @@ The `aName` and `scoped­Name` properties in sub-interfaces are replaced by inhe [[generic_name_omissions]] ====== Omissions -ISO 19103 defines mapping methods from a name to the object identified by that name: +ISO 19103:2015 defines mapping methods from a name to the object identified by that name: `getObject()` in `GenericName` and numerous methods in `NameSpace`. Those methods are not included in GeoAPI interfaces. Instead, we left these mappings to other frameworks, for example _Java Naming and Directory Interface_ (JNDI). diff --git a/src/main/metanorma/sections/informative/internationalization.adoc b/src/main/metanorma/sections/informative/internationalization.adoc index 5c8a8fd00..47af4b07a 100644 --- a/src/main/metanorma/sections/informative/internationalization.adoc +++ b/src/main/metanorma/sections/informative/internationalization.adoc @@ -1,13 +1,13 @@ [[internationalization]] ==== Internationalization -_From <> §C.2_ +_From ISO 19103:2015 §C.2_ The `International­String` interface is defined by GeoAPI to handle textual sequences which may potentially need to be translated for users of different locales. Conceptually this acts as a `Character­String` but may, depending on the implementation, provide access to locale-specific representations of that string. -GeoAPI `International­String` is closely related, but not identical, to ISO 19103 `Language­String`. -The main difference is that the latter is a character string in one specific language, +GeoAPI `International­String` is closely related, but not identical, to ISO 19103:2015 `Language­String`. +The main difference is that the latter was a character string in one specific language, while `International­String` can be a collection of character strings in different locales. This is useful, for example, when an implementation is operating on a server that serves multiple languages simultaneously, to allow sending string representations in the locale of the client rather than the locale of the server running the GeoAPI implementation. @@ -28,7 +28,7 @@ An example in <> shows the use of `International­String` .Linguistic types mapping [options="header"] |============================================================================== -|ISO 19103 interface |Java class or interface |Python class +|ISO 19103:2015 interface |Java class or interface |Python class |`CharacterString` |`java.lang.String` ^(1)^ |`str` |`LanguageString` |`org.opengis.util.InternationalString` |`str` |`LanguageCode` |`java.util.Locale` |`str` @@ -39,8 +39,8 @@ An example in <> shows the use of `International­String` Notes: * (1) Sometimes substituted by `Char­Sequence` or `International­String`. -* (2) Defined as a unit of measurement in ISO 19103 §C.4.24. -* (3) From ISO 19103 §7.2.10 (<>). +* (2) Defined as a unit of measurement in ISO 19103:2015 §C.4.24. +* (3) From ISO 19103:2015 §7.2.10. [[internationalization_departures]] @@ -51,12 +51,6 @@ as described in the following sub-sections. -[[internationalization_departures_as_renaming]] -====== Renaming -All GeoAPI linguistic types have names and properties different than the ISO 19103 types. -This is either because the ISO types are mapped to types provided by the target language standard library -or because the GeoAPI type is inspired by a similar effort in the target language ecosystem. - [[internationalization_departures_for_harmonization]] ====== Harmonization `InternationalString` as defined by GeoAPI provides the same functionality as ISO 19115 `PT_FreeText`. diff --git a/src/main/metanorma/sections/informative/records.adoc b/src/main/metanorma/sections/informative/records.adoc index 5336c25f7..7341b22b9 100644 --- a/src/main/metanorma/sections/informative/records.adoc +++ b/src/main/metanorma/sections/informative/records.adoc @@ -1,13 +1,20 @@ [[records]] ==== Record types -_From <> §7.7_ +_From ISO 19103:2015 §7.7_ + +[WARNING] +========= +Record data types have been removed from ISO 19103:2024. +But they are still used in GeoAPI 3 for historical reasons. +This section is based on the previous version of the ISO 19103 standard. +========= Records define new data type as a heterogeneous aggregation of component data types (the fields). A `Record­Type` defines a dynamically constructed data type. It is identified by a `Type­Name` and contains an arbitrary number of fields as (_name_, _type_) pairs. A `Record` is an instance of `Record­Type` containing the actual field values. -.Records derived and extended from ISO 19103 +.Records derived and extended from ISO 19103:2015 image::records.svg[UML of record objects] `Record` and `RecordType` are lookup mechanisms that associate field names to _values_ and _value types_ respectively. @@ -21,7 +28,7 @@ but they can nevertheless be useful as marker interfaces. .Record types mapping [options="header"] |==================================================================================================== -|ISO 19103 interface |Java class or interface |Python class +|ISO 19103:2015 type |Java class or interface |Python class |`Any` |`java.lang.Object` | |`Type` |`org.opengis.util.Type` | |`Record` |`org.opengis.util.Record` |`opengis.metadata.naming.Record` @@ -46,7 +53,7 @@ The `isInstance(…)` method is a GeoAPI extension. [[records_omissions]] ====== Omissions -The ISO 19103 `Field` and `Field­Type` interfaces are omitted because the same functionality is achieved +The ISO 19103:2015 `Field` and `Field­Type` interfaces are omitted because the same functionality is achieved with `Dictionary` and `Dictionary` respectively. Dictionaries are realized by language-specific types such as `java​.util​.Map` (see collection types in <>) which offer more flexibility. diff --git a/src/main/metanorma/sections/informative/units.adoc b/src/main/metanorma/sections/informative/units.adoc index ced5d0e0f..fd146ce37 100644 --- a/src/main/metanorma/sections/informative/units.adoc +++ b/src/main/metanorma/sections/informative/units.adoc @@ -1,14 +1,21 @@ [[units]] ==== Units of measurement -_From <> §C.4_ +_From <> §8.2.14_ ISO 19103 represents measurements and their units by two base interfaces: `Measure` for the result from performing the act of ascertaining the value of a characteristic of some entity, and `UnitOf­Measure` as a quantity adopted as a standard of measurement for other quantities of the same kind. -These two base interfaces have a parallel set of subtypes. -For example, `Length` as a `Measure` specialization for distances, +These two base interfaces can be specialized with parallel sets of subtypes. +For example, `Length` could be defined as a `Measure` specialization for distances, accompanied by `UomLength` as a `UnitOf­Measure` specialization for length units. -Likewise `Area` is accompanied with `UomArea`, `Time` is accompanied with `UomTime`, _etc._ +Likewise, `Area` could be defined together with `UomArea`, `Time` together with `UomTime`, _etc._ + +[NOTE] +====== +ISO 19103:2015 §C.4 defined many subtypes such as `Area`, `UomArea`, _etc_. +ISO 19103:2024 defines only the base types. +The legacy subtypes are listed in <>. +====== GeoAPI does not define any interface for the ISO 19103 `Measure` and `UnitOf­Measure` types because {supported-languages} already have their own library for units of measurement. diff --git a/src/main/metanorma/sections/informative/web_types.adoc b/src/main/metanorma/sections/informative/web_types.adoc deleted file mode 100644 index 0ffdee6ed..000000000 --- a/src/main/metanorma/sections/informative/web_types.adoc +++ /dev/null @@ -1,25 +0,0 @@ -[[web_types]] -==== Web types -_From <> §C.3_ - -ISO 19103 defines the following data types for use in World Wide Web environments. -These types are often found in XML documents. -GeoAPI maps the ISO types to standard types of the target languages without introducing new interfaces. - -.Web types mapping -[options="header"] -|========================================================== -|ISO 19103 interface |Java class or interface |Python class -|`Anchor` |unimplemented | -|`FileName` |`java.nio.Path` | -|`MediaType` |unimplemented | -|`URI` |`java.net.URI` | -|========================================================== - - -[[web_types_departures]] -===== Departures from ISO model - -All ISO 19103 web types extend `Character­String`. -But this is not the case for equivalent objects provided by the standard Java library. -Consequently, a character string cannot easily be substituted by an anchor, file name or URI in GeoAPI for Java. diff --git a/src/main/metanorma/sections/profiles/java/uom_jsr.adoc b/src/main/metanorma/sections/profiles/java/uom_jsr.adoc index 317908f02..8da2a9ff9 100644 --- a/src/main/metanorma/sections/profiles/java/uom_jsr.adoc +++ b/src/main/metanorma/sections/profiles/java/uom_jsr.adoc @@ -4,41 +4,41 @@ The Java profile of GeoAPI does not materialize any of the units of measurement types (<>) defined by ISO 19103. Instead, unit modeling is entirely delegated to the Java Specification Request <>. The ISO 19103 `Measure` type is represented by the JSR 385 `Quantity` interface. -The Java standard defines various quantity subtypes in the same way as ISO 19103 does, -often with the same names (`Angle`, `Length`, `Area`, `Volume`, _etc_). -But contrarily to ISO 19103, JSR 385 does not define a parallel set of subtypes for units of measurement. +The Java standard defines various quantity subtypes such as `Angle`, `Length`, `Area`, `Volume`, _etc_. +But JSR 385 does not define a parallel set of subtypes for units of measurement. Instead, it defines only one unit type, `javax​.measure​.Unit>`, which is parameterized by the quantity type `Q`. For example instead of defining a `UomLength` subtype, developers use `Unit` to qualify the type of Unit or Measure being used. More examples are given in <>. -The mapping for ISO 19103 measurement types is shown below. +The mapping for ISO 19103:2015 measurement types is shown below. Unless otherwise specified, all Java types listed below are in the `javax.measure` or `javax.measure.quantity` package. +[[uom-mapping]] .Units of measurement mapping [options="header"] -|====================================================================================== -|Measure in ISO 19103 |Unit in ISO 19103 |Measure in Java |Unit in Java -|`Measure` |`UnitOfMeasure` |`Quantity` |`Unit` -|`╴ Angle` |`UomAngle` |`Angle` |`Unit` -|`╴ AngularSpeed` |`UomAngularSpeed` |`Quantity` |`Unit` -|`╴ Area` |`UomArea` |`Area` |`Unit` -|`╴ Currency` |`UomCurrency` | |`java.util.Currency` -|`╴ Length` |`UomLength` |`Length` |`Unit` -|`  └ Distance` |`UomLength` |`Length` |`Unit` -|`╴ Scale` |`UomScale` |`Dimensionless` |`Unit` -|`╴ Speed` |`UomSpeed` |`Speed` |`Unit` -|`╴ TimeMeasure` |`UomTime` |`Time` |`Unit