VehicleFeatureRef and definition of those

[ue71603]

For VehicleFeatureRef it is mentioned, that the they base on TPEG and reference to facilities packaged

	<xsd:complexType name="VehicleFeatureRefStructure">
		<xsd:annotation>
			<xsd:documentation>Type for reference to a Vehicle Feature Code. SIRI provides a recommended set of values covering most usages, intended to be TPEG comnpatible. See the SIRI facilities packaged.</xsd:documentation>
		</xsd:annotation>

At least there is a typo (and it is repeated multiple time sin siri_feature_support)
But also the detailed definition is not shown it is simply an xsd:NMTOKEN

	<xsd:simpleType name="VehicleFeatureCodeType">
		<xsd:annotation>
			<xsd:documentation>Type for identifier of a Vehicle Feature. SIRI provides a recommended set of values covering most usages, intended to be TPEG comnpatible. See the SIRI facilities packaged.</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:NMTOKEN"/>
	</xsd:simpleType>

This does not make me happy. If this is an enum, it should be defined.

What should be used there?

[Aurige]

We wanted to have it open ended, with recommended values that are provided in the SIRI document (but we could have them here as a comment).
It is not based on TPEG, but initially done to be TPEG compatible.
If we put an enumeration it is not open-ended anymore, and it is not easy to be comprehensive for VehicleFeature (neither future proof).
However these are just the reasons why it was done that way, but we can of course rework it with the group.

[ue71603]

I would agree, however, I still want to have a list of things where there exists a common understanding. Otherwise, it can't be processed by machines, I guess. We do it in the xsd:documentation?

[haeckerbaer]

VehicleFeatureRef being open ended means that national profiles are able to define their own value sets without having to request schema updates, which is certainly a good thing. I would argue that the "common understanding" is the recommended values based on the NeTEx definitions. We could either define a union (of the explicitly supported values and <xs:restriction base="xs:nmtoken"/>) or just list the values in the annotations. The latter is a bit messy, considering the number of enums.. What do you propose @ue71603 ?

[ue71603]

Starting with the list of values in the xsd:documentation is a good start and we can leave it at that.
However, if something ends with Ref it should be a reference. Otherwise Code or so should be used.