You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just came across a kind of funny error when validating a CPACS 2.1 file via our CPACS validator webservice:
CPACS document is invalid for schema version 3.1: "Element 'cpacsVersion': [facet 'enumeration'] The value '2.1' is not an element of the set {'3.09999990463257e+00'}."
CPACS document is invalid for schema version 3.2: "Element 'cpacsVersion': [facet 'enumeration'] The value '2.1' is not an element of the set {'3.20000004768372e+00'}."
So it seems that the lxml parser really interprets the string 3.1 and 3.2 in the respective schema documents as floats and thus cannot compare them to the cpacsVersion which is e.g. 2.1.
One cause could be that cpacsVersion is a stringBaseType but receives a restriction to xsd:float with enum values that cannot be represented in binary.
Applies to headerType and updateType.
On the other hand, if lxml knows the expted enum type, it should equally convert the value of the CPACS file to float before comparing, so it may be a bug in lxml.
The text was updated successfully, but these errors were encountered:
Is cpacsVersion really a stringBaseType? It seems to be a simpleType.
I would suggest making it a stringBaseType which would allow versions such as 3.3-beta1 to be used for beta releases. Otherwise cpacs files using a beta version can be confused with the final release.
With CPACS 3.4 it was restricted to xsd:string to account for patch versions (e.g, 3.3.1) (DLR-SC/tigl#830).
<xsd:elementname="cpacsVersion"minOccurs="0">
<xsd:annotation>
<xsd:documentation>CPACS version that the dataset is valid to. The element is optional, since data sets
can be valid for several CPACS versions. However, we strongly recommend to assign data sets to a
specific CPACS version as far as possible, especially since some tools and libraries (e.g. TiGL)
require this specification.
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restrictionbase="xsd:string">
<xsd:enumerationvalue="3.4"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
I just came across a kind of funny error when validating a CPACS 2.1 file via our CPACS validator webservice:
So it seems that the lxml parser really interprets the string
3.1
and3.2
in the respective schema documents as floats and thus cannot compare them to thecpacsVersion
which is e.g.2.1
.One cause could be that
cpacsVersion
is astringBaseType
but receives a restriction toxsd:float
with enum values that cannot be represented in binary.Applies to
headerType
andupdateType
.On the other hand, if lxml knows the expted enum type, it should equally convert the value of the CPACS file to float before comparing, so it may be a bug in lxml.
The text was updated successfully, but these errors were encountered: