From 0d08cfaf9b4878132c366f942c82f891b07be830 Mon Sep 17 00:00:00 2001 From: Heidi Vanparys Date: Mon, 23 Jan 2023 09:57:51 +0100 Subject: [PATCH] =?UTF-8?q?Replace=20<<=20and=20>>=20by=20=C2=AB=20and=20?= =?UTF-8?q?=C2=BB=20for=20keywords=20and=20stereotypes?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace the duplicated “greater than” (>>) or “less than” (<<) symbols by guillements (« and »). From the UML specification: > Guillemets are a special kind of quotation marks and should not be > confused with or replaced by duplicated “greater than” (>>) or “less > than” (<<) symbols, except in situations where the available character > set may not include guillemets. --- requirements/codelists-basic/REQ001.adoc | 2 +- requirements/codelists-basic/REQ002.adoc | 2 +- .../codelists-link-object/REQ001.adoc | 2 +- requirements/codelists-literal/REQ001.adoc | 2 +- requirements/codelists-uri/REQ001.adoc | 2 +- requirements/core/REQ009.adoc | 2 +- requirements/core/REQ010.adoc | 2 +- requirements/core/REQ013.adoc | 2 +- requirements/core/REQ017.adoc | 2 +- requirements/core/REQ018.adoc | 2 +- requirements/geojson-formats/REQ004.adoc | 8 ++-- requirements/jsonfg/REQ003.adoc | 4 +- requirements/jsonfg/REQ004.adoc | 4 +- requirements/jsonfg/REQ005.adoc | 8 ++-- .../union-property-choice/REQ001.adoc | 2 +- .../union-type-discriminator/REQ001.adoc | 2 +- sections/clause_2_conformance.adoc | 2 +- sections/clause_4_terms_and_definitions.adoc | 6 +-- sections/clause_7_normative_text.adoc | 48 +++++++++---------- 19 files changed, 52 insertions(+), 52 deletions(-) diff --git a/requirements/codelists-basic/REQ001.adoc b/requirements/codelists-basic/REQ001.adoc index ff9656a..4852611 100644 --- a/requirements/codelists-basic/REQ001.adoc +++ b/requirements/codelists-basic/REQ001.adoc @@ -2,6 +2,6 @@ ==== [%metadata] identifier:: http://www.opengis.net/spec/uml2json/1.0/req/codelists-basic/schema-definition -statement:: A \<> shall be converted to a JSON Schema definition of a JSON object. That definition shall be added to the definitions schema, using the type name as definition key. +statement:: A «CodeList» shall be converted to a JSON Schema definition of a JSON object. That definition shall be added to the definitions schema, using the type name as definition key. ==== diff --git a/requirements/codelists-basic/REQ002.adoc b/requirements/codelists-basic/REQ002.adoc index f64e411..047c204 100644 --- a/requirements/codelists-basic/REQ002.adoc +++ b/requirements/codelists-basic/REQ002.adoc @@ -2,6 +2,6 @@ ==== [%metadata] identifier:: http://www.opengis.net/spec/uml2json/1.0/req/codelists-basic/codelist-tag -statement:: If the \<> has tag _codeList_ (which is defined by <>), with a non-blank value, then a "codeList" member shall be added to the JSON Schema definition of the code list, with the tag value as value. +statement:: If the «CodeList» has tag _codeList_ (which is defined by <>), with a non-blank value, then a "codeList" member shall be added to the JSON Schema definition of the code list, with the tag value as value. ==== diff --git a/requirements/codelists-link-object/REQ001.adoc b/requirements/codelists-link-object/REQ001.adoc index 01547ae..582c331 100644 --- a/requirements/codelists-link-object/REQ001.adoc +++ b/requirements/codelists-link-object/REQ001.adoc @@ -2,6 +2,6 @@ ==== [%metadata] identifier:: http://www.opengis.net/spec/uml2json/1.0/req/codelists-link-object/schema-ref -statement:: The JSON Schema definition of a \<> shall have a "$ref" member with value "https://FIXME/schema_definitions.json#/$defs/LinkObject". +statement:: The JSON Schema definition of a «CodeList» shall have a "$ref" member with value "https://FIXME/schema_definitions.json#/$defs/LinkObject". ==== diff --git a/requirements/codelists-literal/REQ001.adoc b/requirements/codelists-literal/REQ001.adoc index fed0f37..b83a0ff 100644 --- a/requirements/codelists-literal/REQ001.adoc +++ b/requirements/codelists-literal/REQ001.adoc @@ -2,6 +2,6 @@ ==== [%metadata] identifier:: http://www.opengis.net/spec/uml2json/1.0/req/codelists-literal/type -statement:: The JSON Schema definition of a \<> shall have a "type" member defined by evaluating tagged value _literalEncodingType_. The tagged value _literalEncodingType_ identifies the conceptual type that applies to the code values. If the tagged value is not set on the code list, or has an empty value, then the literal encoding type is defined to be CharacterString. +statement:: The JSON Schema definition of a «CodeList» shall have a "type" member defined by evaluating tagged value _literalEncodingType_. The tagged value _literalEncodingType_ identifies the conceptual type that applies to the code values. If the tagged value is not set on the code list, or has an empty value, then the literal encoding type is defined to be CharacterString. ==== \ No newline at end of file diff --git a/requirements/codelists-uri/REQ001.adoc b/requirements/codelists-uri/REQ001.adoc index 8433ab8..19cefb2 100644 --- a/requirements/codelists-uri/REQ001.adoc +++ b/requirements/codelists-uri/REQ001.adoc @@ -2,6 +2,6 @@ ==== [%metadata] identifier:: http://www.opengis.net/spec/uml2json/1.0/req/codelists-uri/type -statement:: The JSON Schema definition of a \<> shall have a "type" member with value "string", as well as a "format" member with value "uri". +statement:: The JSON Schema definition of a «CodeList» shall have a "type" member with value "string", as well as a "format" member with value "uri". ==== diff --git a/requirements/core/REQ009.adoc b/requirements/core/REQ009.adoc index b24b036..b2989d4 100644 --- a/requirements/core/REQ009.adoc +++ b/requirements/core/REQ009.adoc @@ -2,6 +2,6 @@ ==== [%metadata] identifier:: http://www.opengis.net/spec/uml2json/1.0/req/core/data-types -statement:: A \<> shall be converted to a JSON Schema definition of a JSON object. That definition shall be added to the definitions schema, using the type name as definition key. +statement:: A «DataType» shall be converted to a JSON Schema definition of a JSON object. That definition shall be added to the definitions schema, using the type name as definition key. ==== diff --git a/requirements/core/REQ010.adoc b/requirements/core/REQ010.adoc index 3e72ed7..1176b7c 100644 --- a/requirements/core/REQ010.adoc +++ b/requirements/core/REQ010.adoc @@ -5,7 +5,7 @@ identifier:: http://www.opengis.net/spec/uml2json/1.0/req/core/enumerations [.component,class=part] -- -An \<> shall be converted to a JSON Schema definition with a type defined by evaluating tagged value _literalEncodingType_ on the enumeration. +An «Enumeration» shall be converted to a JSON Schema definition with a type defined by evaluating tagged value _literalEncodingType_ on the enumeration. The tagged value _literalEncodingType_ identifies the conceptual type that applies to the enumeration values. If the tagged value is not set on the enumeration, or has an empty value, then the literal encoding type is defined to be CharacterString. -- diff --git a/requirements/core/REQ013.adoc b/requirements/core/REQ013.adoc index 1d9bba2..22f9d67 100644 --- a/requirements/core/REQ013.adoc +++ b/requirements/core/REQ013.adoc @@ -5,7 +5,7 @@ identifier:: http://www.opengis.net/spec/uml2json/1.0/req/core/property-multipli [.component,class=part] -- -If the minimum cardinality of a UML property is 1 or greater, and the class that owns the property is not a \<>, then the property shall be listed under the "required" properties of the JSON object to which the property belongs. +If the minimum cardinality of a UML property is 1 or greater, and the class that owns the property is not a «union», then the property shall be listed under the "required" properties of the JSON object to which the property belongs. -- [.component,class=part] diff --git a/requirements/core/REQ017.adoc b/requirements/core/REQ017.adoc index c6425fd..7681932 100644 --- a/requirements/core/REQ017.adoc +++ b/requirements/core/REQ017.adoc @@ -2,7 +2,7 @@ ==== [%metadata] identifier:: http://www.opengis.net/spec/uml2json/1.0/req/core/property-initial-value -statement:: A UML attribute that has an initial value, is owned by a type with identity or a \<>, and whose value type is encoded as one of the simple JSON Schema types "string", "number", "integer", or "boolean", shall be encoded as follows: +statement:: A UML attribute that has an initial value, is owned by a type with identity or a «DataType», and whose value type is encoded as one of the simple JSON Schema types "string", "number", "integer", or "boolean", shall be encoded as follows: [.component,class=part] -- diff --git a/requirements/core/REQ018.adoc b/requirements/core/REQ018.adoc index fb21e4b..0e8951a 100644 --- a/requirements/core/REQ018.adoc +++ b/requirements/core/REQ018.adoc @@ -2,7 +2,7 @@ ==== [%metadata] identifier:: http://www.opengis.net/spec/uml2json/1.0/req/core/association-class -statement:: Before applying the conversion to JSON Schema, a UML association class that is a type with identity (i.e., a class that has stereotype \<>, \<>, no stereotype, or a stereotype that maps to one of these cases), shall be transformed as follows (in the following description the source class of the association is called S and the target class is called T): +statement:: Before applying the conversion to JSON Schema, a UML association class that is a type with identity (i.e., a class that has stereotype «FeatureType», «Type», no stereotype, or a stereotype that maps to one of these cases), shall be transformed as follows (in the following description the source class of the association is called S and the target class is called T): * The association class A is transformed into a regular class with the same name, stereotype, tagged values, constraints, attributes, and relationships. * The association is replaced by two associations, one from S to A ("SA"), and one from A to T ("AT"). diff --git a/requirements/geojson-formats/REQ004.adoc b/requirements/geojson-formats/REQ004.adoc index 6b1c017..20094b2 100644 --- a/requirements/geojson-formats/REQ004.adoc +++ b/requirements/geojson-formats/REQ004.adoc @@ -5,21 +5,21 @@ identifier:: http://www.opengis.net/spec/uml2json/1.0/req/geojson-formats/primar [.component,class=part] -- -If a UML property has tag "jsonPrimaryGeometry" with value equal to, ignoring case, "true", and the property is directly owned (i.e., not inherited) by a \<>, then that property shall be encoded as the primary geometry of the feature type (see part C). +If a UML property has tag "jsonPrimaryGeometry" with value equal to, ignoring case, "true", and the property is directly owned (i.e., not inherited) by a «FeatureType», then that property shall be encoded as the primary geometry of the feature type (see part C). -- [.component,class=part] -- -If the set of (direct and inherited, but ignoring redefined) UML properties of a \<> only contains a single UML property with a geometric type (as defined in <>), and that property is directly owned by the feature type, and that property does not have tag "jsonPrimaryGeometry" with value equal to, ignoring case, "false", then that property shall be encoded as the primary geometry of the feature type (see part C). +If the set of (direct and inherited, but ignoring redefined) UML properties of a «FeatureType» only contains a single UML property with a geometric type (as defined in <>), and that property is directly owned by the feature type, and that property does not have tag "jsonPrimaryGeometry" with value equal to, ignoring case, "false", then that property shall be encoded as the primary geometry of the feature type (see part C). -- [.component,class=part] -- -In the JSON Schema definition of the \<>, the primary geometry property shall be encoded as a type restriction for the top-level "geometry" member. The primary geometry property shall not be encoded within the "properties" member. +In the JSON Schema definition of the «FeatureType», the primary geometry property shall be encoded as a type restriction for the top-level "geometry" member. The primary geometry property shall not be encoded within the "properties" member. -- [.component,class=part] -- -In instance data, the value of the primary geometry property shall be encoded within the (GeoJSON) top-level "geometry" member of the JSON object that represents the \<>. +In instance data, the value of the primary geometry property shall be encoded within the (GeoJSON) top-level "geometry" member of the JSON object that represents the «FeatureType». -- ==== \ No newline at end of file diff --git a/requirements/jsonfg/REQ003.adoc b/requirements/jsonfg/REQ003.adoc index 6f178a2..cba0547 100644 --- a/requirements/jsonfg/REQ003.adoc +++ b/requirements/jsonfg/REQ003.adoc @@ -5,11 +5,11 @@ identifier:: http://www.opengis.net/spec/uml2json/1.0/req/jsonfg/primary-place [.component,class=part] -- -A UML property that is owned by a \<> and that has tag "jsonPrimaryPlace" with value equal to, ignoring case, "true", shall be encoded as a type restriction for the top-level "place" member. The UML property shall not be encoded within the "properties" member. +A UML property that is owned by a «FeatureType» and that has tag "jsonPrimaryPlace" with value equal to, ignoring case, "true", shall be encoded as a type restriction for the top-level "place" member. The UML property shall not be encoded within the "properties" member. -- [.component,class=part] -- -In instance data, the value of such a property shall be encoded within the (JSON-FG) top-level "place" member of the JSON object that represents the \<>. +In instance data, the value of such a property shall be encoded within the (JSON-FG) top-level "place" member of the JSON object that represents the «FeatureType». -- ==== diff --git a/requirements/jsonfg/REQ004.adoc b/requirements/jsonfg/REQ004.adoc index 6cb179c..dbb3358 100644 --- a/requirements/jsonfg/REQ004.adoc +++ b/requirements/jsonfg/REQ004.adoc @@ -5,12 +5,12 @@ identifier:: http://www.opengis.net/spec/uml2json/1.0/req/jsonfg/primary-instant [.component,class=part] -- -A UML property that is owned by a \<> and that has tag "jsonPrimaryInstant" with value equal to, ignoring case, "true", shall not be encoded within the "properties" member. Instead, it shall be encoded as a type restriction for the top-level "time" member. The additional restriction for the "time" member shall be encoded using "$ref" with value "https://FIXME/schema_definitions.json#/$defs/PrimaryInstantOptional", if the minimum multiplicity of the property is 0, otherwise "https://FIXME/schema_definitions.json#/$defs/PrimaryInstantRequired". +A UML property that is owned by a «FeatureType» and that has tag "jsonPrimaryInstant" with value equal to, ignoring case, "true", shall not be encoded within the "properties" member. Instead, it shall be encoded as a type restriction for the top-level "time" member. The additional restriction for the "time" member shall be encoded using "$ref" with value "https://FIXME/schema_definitions.json#/$defs/PrimaryInstantOptional", if the minimum multiplicity of the property is 0, otherwise "https://FIXME/schema_definitions.json#/$defs/PrimaryInstantRequired". -- [.component,class=part] -- -In instance data, the value of such a property shall be encoded within the (JSON-FG) time/date or time/timestamp member of the JSON object that represents the \<>. +In instance data, the value of such a property shall be encoded within the (JSON-FG) time/date or time/timestamp member of the JSON object that represents the «FeatureType». -- ==== diff --git a/requirements/jsonfg/REQ005.adoc b/requirements/jsonfg/REQ005.adoc index 01d32f9..393ae6d 100644 --- a/requirements/jsonfg/REQ005.adoc +++ b/requirements/jsonfg/REQ005.adoc @@ -5,7 +5,7 @@ identifier:: http://www.opengis.net/spec/uml2json/1.0/req/jsonfg/primary-interva [.component,class=part] -- -A UML property that is owned by a \<> and that has tag "jsonPrimaryInterval" with value equal to, ignoring case, one of the allowed values "start", "end", or "interval", shall not be encoded within the "properties" member. +A UML property that is owned by a «FeatureType» and that has tag "jsonPrimaryInterval" with value equal to, ignoring case, one of the allowed values "start", "end", or "interval", shall not be encoded within the "properties" member. NOTE: The value types of UML properties that represent or contribute to the primary interval should be compatible with that use. For example, properties marked as primary interval start or end can have value type "Date", "DateTime", or "TM_Instant", whereas a property marked as primary interval can have value type "TM_Period". @@ -14,16 +14,16 @@ The UML property shall be encoded as a type restriction for the top-level "time" [.component,class=part] -- -A \<> shall satisfy the following conditions: +A «FeatureType» shall satisfy the following conditions: * At most one of the direct properties has tag "jsonPrimaryInterval" = "interval". * At most one of the direct properties has tag "jsonPrimaryInterval" = "start". * At most one of the direct properties has tag "jsonPrimaryInterval" = "end". -* The use of "interval" and "start"/"end" are mutually exclusive within the direct properties of the \<>: If one direct property has tag "jsonPrimaryInterval" = "interval", none of the direct properties shall have tag "jsonPrimaryInterval" equal to "start" or "end". Likewise, if one direct property has tag "jsonPrimaryInterval" equal to "start" or "end", none of the direct properties shall have tag "jsonPrimaryInterval" = "interval". +* The use of "interval" and "start"/"end" are mutually exclusive within the direct properties of the «FeatureType»: If one direct property has tag "jsonPrimaryInterval" = "interval", none of the direct properties shall have tag "jsonPrimaryInterval" equal to "start" or "end". Likewise, if one direct property has tag "jsonPrimaryInterval" equal to "start" or "end", none of the direct properties shall have tag "jsonPrimaryInterval" = "interval". -- [.component,class=part] -- -In instance data, the value of properties that represent or constitute to the primary interval shall be encoded within the (JSON-FG) time/interval member of the JSON object that represents the \<>. +In instance data, the value of properties that represent or constitute to the primary interval shall be encoded within the (JSON-FG) time/interval member of the JSON object that represents the «FeatureType». -- ==== diff --git a/requirements/union-property-choice/REQ001.adoc b/requirements/union-property-choice/REQ001.adoc index b1365d9..6aaca03 100644 --- a/requirements/union-property-choice/REQ001.adoc +++ b/requirements/union-property-choice/REQ001.adoc @@ -3,7 +3,7 @@ [%metadata] identifier:: http://www.opengis.net/spec/uml2json/1.0/req/union-property-choice/encoding -part:: A \<> shall be encoded as a JSON Schema definition of a JSON object, where each union option is represented as an optional member of the JSON object. +part:: A «union» shall be encoded as a JSON Schema definition of a JSON object, where each union option is represented as an optional member of the JSON object. part:: The choice between the options defined by the union shall be encoded using "maxProperties" = "minProperties" = 1. That is, the number of members that are allowed for the JSON object is restricted to exactly one. part:: An `"additionalProperties": false` shall be used to prevent any undefined properties. diff --git a/requirements/union-type-discriminator/REQ001.adoc b/requirements/union-type-discriminator/REQ001.adoc index 76b72e8..99f2740 100644 --- a/requirements/union-type-discriminator/REQ001.adoc +++ b/requirements/union-type-discriminator/REQ001.adoc @@ -3,7 +3,7 @@ [%metadata] identifier:: http://www.opengis.net/spec/uml2json/1.0/req/union-type-discriminator/encoding -A \<> shall be encoded as a JSON Schema definition that represents a choice between the value types of the union properties. +A «union» shall be encoded as a JSON Schema definition that represents a choice between the value types of the union properties. * If the value types are only simple, without a specific format definition or other restrictions defined by JSON Schema keywords, then the JSON Schema shall only contain a "type" member, with an array of the simple types. * Otherwise, a "oneOf" member shall be added to the JSON Schema definition, with: diff --git a/sections/clause_2_conformance.adoc b/sections/clause_2_conformance.adoc index 6200738..8d445a3 100644 --- a/sections/clause_2_conformance.adoc +++ b/sections/clause_2_conformance.adoc @@ -14,7 +14,7 @@ Common encoding behavior is defined in the core requirements class (<>), and ** a JSON-FG encoding (<>). * There are two requirements classes that represent options for realizing a by-reference encoding of property values, one using URIs (<>, and one using link objects <>). -* Requirements classes also exist for the two ways in which \<> types are used in practice: as type discriminator (<>) and as property choice (<>). +* Requirements classes also exist for the two ways in which «union» types are used in practice: as type discriminator (<>) and as property choice (<>). * Code list valued properties can be represented in one of three ways, defined by requirements classes: as a literal (<>), as URI (<>), and as link object (<>). * Finally, an additional requirements class supports the encoding of a JSON member for storing the name of the conceptual type that a JSON object encodes (<>). diff --git a/sections/clause_4_terms_and_definitions.adoc b/sections/clause_4_terms_and_definitions.adoc index 2661981..b4fa2bc 100644 --- a/sections/clause_4_terms_and_definitions.adoc +++ b/sections/clause_4_terms_and_definitions.adoc @@ -15,15 +15,15 @@ Source: https://www.w3.org/2001/sw/wiki/Semantic_Web_terminology#linked_data[W3C ==== feature type -A _feature type_ as defined by the General Feature Model (see <>). In an application schema, a _feature type_ is typically modeled using stereotype \<>, or a stereotype that maps to that stereotype. +A _feature type_ as defined by the General Feature Model (see <>). In an application schema, a _feature type_ is typically modeled using stereotype «FeatureType», or a stereotype that maps to that stereotype. ==== object type -An _object type_ is a standard class, instances are plain objects with identity. An _object type_ is not a _feature type_. In an application schema, an _object type_ has no stereotype, or has stereotype \<>, or has a stereotype that maps to one of these two options. +An _object type_ is a standard class, instances are plain objects with identity. An _object type_ is not a _feature type_. In an application schema, an _object type_ has no stereotype, or has stereotype «Type», or has a stereotype that maps to one of these two options. ==== data type -As defined by <>, section 6.10, a _data type_ is a class with stereotype \<> (or a stereotype that maps to that stereotype), which is a set of properties that lacks identity. +As defined by <>, section 6.10, a _data type_ is a class with stereotype «DataType» (or a stereotype that maps to that stereotype), which is a set of properties that lacks identity. ==== type with identity diff --git a/sections/clause_7_normative_text.adoc b/sections/clause_7_normative_text.adoc index bd0b712..91704cc 100644 --- a/sections/clause_7_normative_text.adoc +++ b/sections/clause_7_normative_text.adoc @@ -19,7 +19,7 @@ The stereotypes as well as tagged values that are relevant for JSON Schema encod |=== | Stereotype / keyword | Model element | Description |applicationSchema |Package |A conceptual schema for data required by one or more applications. Source: <>, especially chapter 8.2. -|schema |Package |This stereotype is typically used in abstract schemas defined by ISO TC 211. For further details on abstract schemas, see <>, chapter 6.2 and figure 4. An abstract schema and an application schema are both conceptual schemas, but they are on different levels of abstraction. The stereotype \<> has been introduced for schemas that conform to ISO 19103, but do not follow the rules for application schemas from ISO 19109, but still need a stereotype on the schema package for adding tagged values. +|schema |Package |This stereotype is typically used in abstract schemas defined by ISO TC 211. For further details on abstract schemas, see <>, chapter 6.2 and figure 4. An abstract schema and an application schema are both conceptual schemas, but they are on different levels of abstraction. The stereotype «Schema» has been introduced for schemas that conform to ISO 19103, but do not follow the rules for application schemas from ISO 19109, but still need a stereotype on the schema package for adding tagged values. |featureType |Class |A feature type as defined by <>. |interface - for backwards-compatibility to UML 1 schemas (that comply with earlier versions of <>) also: type |Class |An abstract classifier with operations, attributes and associations, which can only inherit from or be inherited by other interfaces. Other classifiers may realize an interface by implementing its operations and supporting its attributes and associations (at least through derivation). Source: <> This stereotype is typically used in conceptual schemas from ISO TC 211. It should not be used in application schemas, as these are on a different conceptual level than classifiers with this stereotype. |dataType |Class |A set of properties that lack identity (independent existence and the possibility of side effects). A data type is a classifier with no operations, whose primary purpose is to hold information. Source: <> @@ -32,7 +32,7 @@ The stereotypes as well as tagged values that are relevant for JSON Schema encod NOTE: Communities may use aliases for the stereotypes listed above. -NOTE: Some conceptual schemas and application schemas do not make use of the stereotypes \<>, but still attach certain tagged values to according properties in their UML model. That approach is supported by some UML modeling tools, even though tagged values typically belong to a certain stereotype. For the purposes of this specification, the stereotype \<> is assumed to be applied in schemas that shall be converted from UML to JSON Schema. Nevertheless, it is allowed for schemas to omit the stereotypes, and just use the associated tagged values (see below) on according model elements. This kind of use implies the presence of an ad-hoc stereotype, which is considered to represent the \<> stereotype. +NOTE: Some conceptual schemas and application schemas do not make use of the stereotypes «property», but still attach certain tagged values to according properties in their UML model. That approach is supported by some UML modeling tools, even though tagged values typically belong to a certain stereotype. For the purposes of this specification, the stereotype «property» is assumed to be applied in schemas that shall be converted from UML to JSON Schema. Nevertheless, it is allowed for schemas to omit the stereotypes, and just use the associated tagged values (see below) on according model elements. This kind of use implies the presence of an ad-hoc stereotype, which is considered to represent the «property» stereotype. <> lists the tagged values relevant for the JSON Schema encodings, together with the stereotype(s) they apply to, as well as relevant requirements class(es). @@ -41,10 +41,10 @@ NOTE: Some conceptual schemas and application schemas do not make use of the ste [width="90%",options="header"] |=== | Applicable stereotype(s) | Tagged value | Relevant requirements class(es) | Comment -.2+| \<> and \<> | jsonDocument | xref:http://www.opengis.net/spec/uml2json/1.0/req/core[style=id%] .2+| see <> +.2+| «applicationSchema» and «schema» | jsonDocument | xref:http://www.opengis.net/spec/uml2json/1.0/req/core[style=id%] .2+| see <> | jsonId | xref:http://www.opengis.net/spec/uml2json/1.0/req/core[style=id%] -| \<> and \<> | literalEncodingType |xref:http://www.opengis.net/spec/uml2json/1.0/req/core[style=id%] and xref:http://www.opengis.net/spec/uml2json/1.0/req/codelists-literal[style=id%] | see <> and <> -.13+| \<> | inlineOrByReference | xref:http://www.opengis.net/spec/uml2json/1.0/req/by-reference-basic[style=id%] | see <> +| «Enumeration» and «CodeList» | literalEncodingType |xref:http://www.opengis.net/spec/uml2json/1.0/req/core[style=id%] and xref:http://www.opengis.net/spec/uml2json/1.0/req/codelists-literal[style=id%] | see <> and <> +.13+| «property» | inlineOrByReference | xref:http://www.opengis.net/spec/uml2json/1.0/req/by-reference-basic[style=id%] | see <> | jsonPrimaryGeometry | xref:http://www.opengis.net/spec/uml2json/1.0/req/geojson-formats[style=id%] | see <> | jsonPrimaryInstant | xref:http://www.opengis.net/spec/uml2json/1.0/req/jsonfg[style=id%] .2+| see <> | jsonPrimaryInterval | xref:http://www.opengis.net/spec/uml2json/1.0/req/jsonfg[style=id%] @@ -69,7 +69,7 @@ include::../requirements/core/requirements_class.adoc[] [[jsonschema_req_core_definitionsschema]] ==== Definitions schema -Schema packages have the stereotype \<>, \<>, or an alias (e.g., using a specific language, like in German: \<>). An \<> package represents an application schema according to ISO 19109. The stereotype \<> has been introduced for packages that should be treated like application schemas, but do not contain feature types. +Schema packages have the stereotype «applicationSchema», «schema», or an alias (e.g., using a specific language, like in German: «anwendungsschema»). An «applicationSchema» package represents an application schema according to ISO 19109. The stereotype «schema» has been introduced for packages that should be treated like application schemas, but do not contain feature types. include::../requirements/core/REQ001.adoc[] @@ -366,7 +366,7 @@ This approach to converting a generalization relationship has the following rest [[jsonschema_req_core_types_common_base]] ===== Common base schema -It is often useful to encode all classes that have a certain stereotype with a common base type. The generalization relationship to such a base type is often implied with the stereotype, for a given encoding. In GML, for example, the common base type for classes with stereotype \<> is gml:AbstractFeature. Rather than explicitly modeling such a base type (e.g., _AnyFeature_ defined by ISO 19109), as well as explicitly modeling generalization relationships to the base type, the encoding rule typically takes care of adding that relationship to relevant schema types. Requirements class xref:http://www.opengis.net/spec/uml2json/1.0/req/core[style=id%] does not declare specific common base types. That is left to other requirements classes. +It is often useful to encode all classes that have a certain stereotype with a common base type. The generalization relationship to such a base type is often implied with the stereotype, for a given encoding. In GML, for example, the common base type for classes with stereotype «FeatureType» is gml:AbstractFeature. Rather than explicitly modeling such a base type (e.g., _AnyFeature_ defined by ISO 19109), as well as explicitly modeling generalization relationships to the base type, the encoding rule typically takes care of adding that relationship to relevant schema types. Requirements class xref:http://www.opengis.net/spec/uml2json/1.0/req/core[style=id%] does not declare specific common base types. That is left to other requirements classes. [[jsonschema_req_core_types_featureandobjecttype]] @@ -407,7 +407,7 @@ The literal encoding type is one of the types from ISO 19103, which are implemen |==================== [[img_req_core_enumeration_example]] -.\<> example +.«Enumeration» example image::figures/Enumeration_example.png[align="center"] [[example_req_core_jsonschema_enumeration]] @@ -558,7 +558,7 @@ image::figures/basic_types_example.png[align="center"] include::../requirements/core/REQ012.adoc[] -NOTE: By default, UML properties are converted to keys within the "properties" member of the JSON Schema definition for the type that owns the property. Additional requirements may override this encoding (e.g., the <> of \<> properties), or augment the encoding (e.g., <>). +NOTE: By default, UML properties are converted to keys within the "properties" member of the JSON Schema definition for the type that owns the property. Additional requirements may override this encoding (e.g., the <> of «union» properties), or augment the encoding (e.g., <>). The default result of converting a UML property, therefore, is a key within the "properties" key of the JSON Schema definition for the type that owns the property, with the key name being the name of the UML property, and the value being a JSON Schema with constraints and annotations that define the property (value type, multiplicity, etc). @@ -896,7 +896,7 @@ NOTE: Properties of object types are encoded as first-level properties of the re include::../requirements/geojson-formats/REQ004.adoc[] -NOTE: UML properties of other kinds of classes - object types, data types, and unions - are not considered by this requirement. Object types are not encoded as GeoJSON features. Data types and unions may be used by other classes, which prevents a general exclusive mapping to the GeoJSON top-level "geometry" member. Only a direct property of a \<> can be mapped in this way. +NOTE: UML properties of other kinds of classes - object types, data types, and unions - are not considered by this requirement. Object types are not encoded as GeoJSON features. Data types and unions may be used by other classes, which prevents a general exclusive mapping to the GeoJSON top-level "geometry" member. Only a direct property of a «FeatureType» can be mapped in this way. [[img_req_geojson_formats_primary_geometry_example]] .Example of a feature type with an attribute designated as primary geometry @@ -1063,7 +1063,7 @@ An example of encoding feature types with a common base schema is given in <> can be mapped in this way. +NOTE: UML properties of other kinds of classes - object types, data types, and unions - are not considered by this requirement. Object types are not encoded as JSON-FG features. Data types and unions may be used by other classes, which prevents a general exclusive mapping to the JSON-FG top-level "place" member. Only a direct property of a «FeatureType» can be mapped in this way. [[img_req_jsonfg_primary_place_example]] .Example of a feature type with an attribute designated as primary place @@ -1102,11 +1102,11 @@ image::figures/example_primary_place.png[align="center"] include::../requirements/jsonfg/REQ004.adoc[] -NOTE: UML properties of other kinds of classes - object types, data types, and unions - are not considered by this requirement. Object types are not encoded as JSON-FG features. Data types and unions may be used by other classes, which prevents a general exclusive mapping to the JSON-FG top-level "time" member. Only a direct property of a \<> can be mapped in this way. +NOTE: UML properties of other kinds of classes - object types, data types, and unions - are not considered by this requirement. Object types are not encoded as JSON-FG features. Data types and unions may be used by other classes, which prevents a general exclusive mapping to the JSON-FG top-level "time" member. Only a direct property of a «FeatureType» can be mapped in this way. include::../requirements/jsonfg/REQ005.adoc[] -NOTE: UML properties of other kinds of classes - object types, data types, and unions - are not considered by this requirement. Object types are not encoded as JSON-FG features. Data types and unions may be used by other classes, which prevents a general exclusive mapping to the JSON-FG top-level "time" member. Only a direct property of a \<> can be mapped in this way. +NOTE: UML properties of other kinds of classes - object types, data types, and unions - are not considered by this requirement. Object types are not encoded as JSON-FG features. Data types and unions may be used by other classes, which prevents a general exclusive mapping to the JSON-FG top-level "time" member. Only a direct property of a «FeatureType» can be mapped in this way. [[img_req_jsonfg_primary_time_example]] .Example of a feature type with an attribute designated as primary instant @@ -1161,7 +1161,7 @@ Multiple options exist for realizing the by-reference encoding of property value NOTE: The conversion behavior does not support by reference encoding for value types that are data types. In general, a data type does not have identity, and therefore a data type value should always be encoded inline, not by reference. -// Likely irrelevant for the Best Practice: The XML Schema encoding rule defined by ISO 19139:2007, typically used to encode metadata schemas (as defined by ISO 19115, and extensions thereof), on the other hand, allows by reference encoding for data type values. When comparing the version of ISO 19115 from 2003/2006 against the version from 2014, it is apparent that some classes that were defined as data types in the previous version have been changed to object types, for example _CI_Citation_. This indicates that the assignment of the \<> stereotype has been corrected, in order to reflect in the conceptual model that the type shall be a type with identity. +// Likely irrelevant for the Best Practice: The XML Schema encoding rule defined by ISO 19139:2007, typically used to encode metadata schemas (as defined by ISO 19115, and extensions thereof), on the other hand, allows by reference encoding for data type values. When comparing the version of ISO 19115 from 2003/2006 against the version from 2014, it is apparent that some classes that were defined as data types in the previous version have been changed to object types, for example _CI_Citation_. This indicates that the assignment of the «DataType» stereotype has been corrected, in order to reflect in the conceptual model that the type shall be a type with identity. // Interestingly, there is an early activity of standardizing or harmonizing references in JSON: https://github.com/json-schema-org/referencing. However, that activity is still ongoing (as of November, 2022) and there are competing proposals. @@ -1319,9 +1319,9 @@ This JSON object is valid against the schema definition of "Parcel" from <>. +Application schemas have two ways of using types with stereotype «union». -* According to ISO 19103:2015, a \<> type consists __"of one and only one of several alternative datatypes (listed as member attributes). This is similar to a discriminated union in many programming languages"__. According to this definition, only the types of the UML attributes defined for a \<> are of interest. +* According to ISO 19103:2015, a «union» type consists __"of one and only one of several alternative datatypes (listed as member attributes). This is similar to a discriminated union in many programming languages"__. According to this definition, only the types of the UML attributes defined for a «union» are of interest. * In practice, unions defined in application schemas are also used differently, defining a choice between a number of options, where each option is modeled as a UML attribute. In other words, the attribute itself has meaning - not just its value type. Multiple options can have the same value type. Options can have different maximum multiplicity (especially greater than 1). The UML-to-GML application schema encoding rules support this way of using unions (see OGC 07-036r1, section E.2.4.10). The following sections document requirements classes for union encodings that support these two approaches. @@ -1393,11 +1393,11 @@ include::../requirements/union-property-choice/REQ001.adoc[] The result of applying this encoding to the union from <> is shown in <>. [[img_unions_req_property_choice_union_example]] -.\<> example +.«union» example image::figures/Union_example.png[align="center"] [[example_unions_req_property_choice_jsonschema]] -.Example of a JSON Schema for a \<> class, representing the property choice using "minProperties" and "maxProperites" +.Example of a JSON Schema for a «union» class, representing the property choice using "minProperties" and "maxProperites" [source,json,linenumbers] ---- { @@ -1448,7 +1448,7 @@ This JSON object is invalid (because "option2" has a string value, rather than a ==== Overview -This specification defines three approaches for encoding the values of properties that have a \<> as value type: +This specification defines three approaches for encoding the values of properties that have a «CodeList» as value type: * using a simple literal value, e.g., a string or number that represents a code, * using a URI as code value, and @@ -1467,11 +1467,11 @@ include::../requirements/codelists-basic/REQ001.adoc[] include::../requirements/codelists-basic/REQ002.adoc[] [[img_codelists_req_basic_jsonschema_example]] -.Example of a \<> type with tagged value 'codeList' +.Example of a «CodeList» type with tagged value 'codeList' image::figures/code_lists_basic.png[align="center"] [[example_codelists_req_basic_jsonschema]] -.Example of the basic JSON Schema encoding of a \<> type with tagged value 'codeList' +.Example of the basic JSON Schema encoding of a «CodeList» type with tagged value 'codeList' [source,json,linenumbers] ---- { @@ -1497,11 +1497,11 @@ include::../requirements/codelists-literal/REQ001.adoc[] The literal encoding type is one of the types from ISO 19103, which are implemented as a simple JSON Schema type - see <> in <>. [[img_codelists_req_literal_jsonschema_example]] -.Example of \<> types +.Example of «CodeList» types image::figures/code_lists_literal.png[align="center"] [[example_codelists_req_literal_jsonschema]] -.Example of the JSON Schema encodings of \<> types +.Example of the JSON Schema encodings of «CodeList» types [source,json,linenumbers] ---- { @@ -1526,7 +1526,7 @@ include::../requirements/codelists-uri/requirements_class.adoc[] include::../requirements/codelists-uri/REQ001.adoc[] [[example_codelists_req_uri_jsonschema]] -.Example of the JSON Schema encodings of a \<> type with the JSON Schema "type" being a URI +.Example of the JSON Schema encodings of a «CodeList» type with the JSON Schema "type" being a URI [source,json,linenumbers] ---- {