Restriction types and bases in xsd do not show in dataclass binding

[martinwiesmann]

At the moment, if I generate a binding of a compexType which is of type from a simpleType, which itself is a restriction on a base, then both the base and the name of the simpleType are not shown in the complexType binding.

This is probably not a critical issue, but it would be very good to have this information in the binding.

In our project, we need to be able to e.g. distinguish between two different complexTypes, which have the same restrictions but are used in different contexts. Thus for this we would need to know the name of the simpleType.

Not knowing the base type of a restriction can create problems as well, if for example the base type is byte, but the Enum class only returns a string. This would make it impossible to validate (and thus serialise) such an xml product.

If you could fix these issues, that would be great.

[martinwiesmann]

An example of a byte restriction type with enumerations:

<xs:simpleType name="arrayFormat">
    <xs:annotation>
        <xs:documentation>Describes the different formats of the array values. It maps to the FITS keyword BITPIX. It can be one of the following:
            8 - Character or unsigned binary integer (1 byte)
            16 - 16-bit integer (2 bytes)
            32 - 32-bit integer (4 bytes)
            64 - 64-bit integer (8 bytes)
            -32 - single precision floating point (4 bytes)
            -64 - double precision floating point (8 bytes)
        </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:byte">
        <xs:enumeration value="8"/>
        <xs:enumeration value="16"/>
        <xs:enumeration value="32"/>
        <xs:enumeration value="64"/>
        <xs:enumeration value="-32"/>
        <xs:enumeration value="-64"/>
    </xs:restriction>
</xs:simpleType>

becomes:

class ArrayFormat(Enum):
"""Describes the different formats of the array values. It maps to the FITS
keyword BITPIX. It can be one of the following:

8 - Character or unsigned binary integer (1 byte)
16 - 16-bit integer (2 bytes)
32 - 32-bit integer (4 bytes)
64 - 64-bit integer (8 bytes)
-32 - single precision floating point (4 bytes)
-64 - double precision floating point (8 bytes)
"""
VALUE_8 = 8
VALUE_16 = 16
VALUE_32 = 32
VALUE_64 = 64
VALUE_32_1 = -32
VALUE_64_1 = -64

having the metadata say something like:

restriction_base = 'byte'

would be very helpful.

[martinwiesmann]

An example of missing type, that we would like to know:

<xs:simpleType name="limitedString">
	<xs:annotation>
		<xs:documentation>objectId base - string up to 296 characters</xs:documentation>
	</xs:annotation>
	<xs:restriction base="xs:string">
		<xs:minLength value="1"/>
		<xs:maxLength value="296"/>
	</xs:restriction>
</xs:simpleType>
<xs:complexType name="objectId">
	<xs:annotation>
		<xs:documentation> Change type to a xs:string to be more human readable. IAL should ensure the uniqueness with naming rules.
		</xs:documentation>
	</xs:annotation>
	<xs:simpleContent>
		<xs:extension base="limitedString"/>
	</xs:simpleContent>
</xs:complexType>
<xs:complexType name="genericHeader">
	<xs:annotation>
		<xs:documentation>Generic header for all scientific data products processed through IAL.</xs:documentation>
		<xs:appinfo/>
	</xs:annotation>
	<xs:sequence>
		<xs:element name="ProductId" type="objectId">
			<xs:annotation>
				<xs:documentation>This Id is the unique reference of the object defined in this interface, this Id is processed by IAL to ensure the uniqueness. Naming rules specified by concatenation of [PIPELINEId]-[PURPOSE]-[USER]-PLAN-[NUMBER]-PPO-[NUMBER]-TimeStamp-[SDC-PROD]-ATTEMPT-[Number]-out-[number] where [NUMBER] is a running number (see DM),
					each of the fields are defined into the data model : dictionary/sys/orc package</xs:documentation>
			</xs:annotation>
		</xs:element>

becomes:

@dataclass
class GenericHeader:
"""
Generic header for all scientific data products processed through IAL.
"""
class Meta:
    name = "genericHeader"

ProductId: Optional[str] = field(
    default=None,
    metadata={
        "type": "Element",
        "namespace": "",
        "required": True,
        "min_length": 1,
        "max_length": 296,
    }
)

If the 'type' (here: 'objectId') could be in the metadata of 'ProductId' would also be appreciated. Although you already have a keyword 'type' there, so it would need to be another keyword, like maybe 'base_type'.

Or alternatively, define 'ProductId' like this:

ProductId: Optional[objectId] = field(

and the let 'objectId' have its own dataclass.

[skinkie]

Same as #738

[tefra]

I don't see how this is the same as #738 @skinkie

In this case the generator is flattening stuff as much as possible, that's part of xsdata philosophy.
If we keep simple types, or complex types with simple content in, the output would be massive and reduntant.

[skinkie]

If we keep simple types, or complex types with simple content in, the output would be massive and reduntant.

I was under the impression that this was an issue related to inheritance too.

[tefra]

The #738 was about flattening complex base classes when it shouldn't. This case is more about flattening simple types and keeping some sort of record for this.

The #734 is a bit more relevant, I have some ideas how to achieve but it's not my highest priorty right now