Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VehicleFeatureRef and definition of those #106

Open
ue71603 opened this issue Mar 16, 2023 · 2 comments
Open

VehicleFeatureRef and definition of those #106

ue71603 opened this issue Mar 16, 2023 · 2 comments
Assignees

Comments

@ue71603
Copy link
Collaborator

ue71603 commented Mar 16, 2023

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
Copy link
Contributor

Aurige commented Mar 21, 2023

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
Copy link
Collaborator Author

ue71603 commented Mar 22, 2023

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants