BaseTypes_RelatedParty_allow CharacterString additionally to PT_FreeText

[JohannaOtt]

Change proposal description

According to the implementing rules, RelatedParty.individualName, RelatedParty.organisationName and RelatedParty.positionName have PT_FreeText as type.
This is also true for other types defined in the INSPIRE models whereas others use CharacterString when text is required.
As the use of PT_FreeText does not always make sense but does for some use cases/countries, I would propose to allow both, PT_FreeText and CharacterString for all properties that currently use one of them. So far, I only met data providers who wanted to use CharacterString instead of PT_FreeText (not the other way around) but as I assume that PT_FreeText is in use and needed for some other countries/cases, I assume that allowing both would be the easiest solution)
The validator already accepts both (at least in cases where PT_FreeText is demanded in the IR, but CharacterString is used)

Issue faced

PT_FreeText is more complex but not neccessary/fully used in most of the cases.

Current behaviour

Some text properties use PT_FreeText, some use CharacterString. The validator does not check for it.

Proposed solution

PT_FreeText and CharacterString are both allowed for all properties that currently use either, or.

Additional information

Proposal reason

The current schema version does not support the use case that some providers only need simple text fields (CharacterString) whereas others need more complex ones (PT_FreeText).

Addressed schema

All schemas using PT_FreeText and/or CharacterString

Impact on INSPIRE TG / IR

The IR would need to be updated to allow the use of both wherever they occur.

Change proposer

Johanna Ott, wetransform GmbH (on behalf of various customers that want to use CharacterString instead of PT_FreeText in most of the cases).

References

More detailed documentation

This is a follow up ticket of this thread in the INSPIRE Thematic cluster.
It is created because of a proposal in this issue discussing the handling of the two types in the validator.
Both can be read/used as sources for more input/discussions that already took place.

[heidivanparys]

I'm not sure that this is actually an issue?

According to the XML schema that includes RelatedParty, property having PT_FreeText as type are defined as following (example for organisationName):

<element minOccurs="0" name="organisationName" nillable="true" type="gmd:PT_FreeText_PropertyType">

gmd:PT_FreeText_PropertyType is defined as follows according to the freeText.xsd XML schema:

<xs:complexType name="PT_FreeText_PropertyType">
	<xs:complexContent>
		<xs:extension base="gco:CharacterString_PropertyType">
			<xs:sequence minOccurs="0">
				<xs:element ref="gmd:PT_FreeText"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>

So PT_FreeText_PropertyType extends from gco:CharacterString_PropertyType, and the sequence of gmd:PT_FreeText elements is optional.

Meaning that both the following are valid:

<base2:organisationName>
	<gco:CharacterString>NameOfOrganisation</gco:CharacterString>
</base2:organisationName>

<base2:organisationName>
	<gco:CharacterString>NameOfOrganisation</gco:CharacterString>
	<gmd:PT_FreeText>
		<gmd:textGroup>
			<gmd:LocalisedCharacterString locale="https://id.loc.gov/vocabulary/iso639-2/dan">Organisationsnavn</gmd:LocalisedCharacterString>
		</gmd:textGroup>
	</gmd:PT_FreeText>
</base2:organisationName>

One can wonder

• why minOccurs is set to 0 when the UML diagram shows a multiplicity of 1..* on property textGroup;
• or why the UML model actually has a multiplicity of 1..* there.

However, perhaps the pragmatic solution here would not to change anything, and provide only the gco:CharacterString element and no gmd:PT_FreeText when that property is not localised. No change needed in the IR, no change needed in the validator.

[fabiovinci]

Dear @heidivanparys,

thank you for your input. I agree with your conclusion, I had thought about the same.

In addition, I don't see any error with the multiplicities:

• The multiplicity "0" in the PT_FreeText datatype definition refers to the occurrence of the <gmd:PT_FreeText>, which is optional, therefore only the <gco:CharacterString> element can be present.

• The multiplicity "1..*" refers to the occurrences of the gmd:textGroup element inside the <gmd:PT_FreeText> element. So, if the <gmd:PT_FreeText> element is present, one or more gmd:textGroup elements shall be present.

[pawelsoczewski]

I agree with you, there's no need to change XSD Schema for RelatedParty. Currently, both CharacterString and PT_FreeText are allowed. However UML model points to more specific CharacterString implementation which is PT_FreeText.
Therefore, UML should be changed to CharacterString and added note PT_FreeText is allow as more detailed language information.

I don't see any error with the multiplicities as @fabiovin.

[KathiSchleidt]

I have to agree with @pawelsoczewski on the UML issue. Formally, while you can replace a type with a derived type, the opposite (replacing a derived type with it's parent) is incorrect.

[sMorrone]

Subgroup meeting on 13.09.2022:
no need to change XSD, no need to change UML . This issue can be closed as soon as the related content is summarised and made available as implementation example in the Discussions tab of the generic helpdesk.

[sMorrone]

Related "Implementation examples" category discussion: INSPIRE-MIF/helpdesk#135