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

Structs missing in generated go code #80

Open
nettnikl opened this issue Aug 22, 2024 · 4 comments
Open

Structs missing in generated go code #80

nettnikl opened this issue Aug 22, 2024 · 4 comments

Comments

@nettnikl
Copy link

Description

Some simple types are not generated under given circumstances. The original XSD is not created by me, but is i understand, is old and widely used.

I have no clue of XML, but i managed to dumb the issue down to this short code.

Steps to reproduce the issue:

  1. See reproducible minimal example code below.
  2. xgen -l Go -p internal -i resources/xsd/ -o internal/model/
  3. Check the output.

Describe the results you received:
AAA has a struct in go code created.

Describe the results you expected:
GGG and DDD has types in go code created as well.

Output of go version:

go version go1.22.5 linux/amd64

xgen version or commit ID:

xgen version: 0.1.0
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        targetNamespace="http://example.com/schemas"
        xmlns:ak="http://example.com/schemas"
        elementFormDefault="qualified">

    <xsd:complexType name="AAA">
        <xsd:annotation><xsd:documentation>BBB</xsd:documentation></xsd:annotation>
        <xsd:sequence>
            <xsd:element name="CCC">
                <xsd:simpleType>
                    <xsd:restriction base="ak:GGG">
                        <!-- This seems to be the issue, CCC is not generated with this restriction enabled -->
                        <xsd:minLength value = "4" fixed = "true" />
                    </xsd:restriction>
                </xsd:simpleType>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:simpleType name="DDD">
        <xsd:annotation><xsd:documentation>EEE</xsd:documentation></xsd:annotation>
        <xsd:restriction base="ak:GGG">
            <!-- While CCC is ok, this is okay as well. While CCC has the invalid restriction: if any of the following it commented in, DDD is not generated anymore as well. -->
<!--            <xsd:whiteSpace value="collapse" />
<!--            <xsd:minLength value="1" />-->
<!--            <xsd:maxLength value="43" />-->
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="GGG">
        <xsd:annotation><xsd:documentation>FFF</xsd:documentation></xsd:annotation>
        <xsd:restriction base="xsd:string"/>
    </xsd:simpleType>
    
</xsd:schema>

Environment details (OS, physical, etc.):

@nettnikl
Copy link
Author

Is this the same issue?

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        targetNamespace="http://example.com/schemas"
        xmlns:ak="http://example.com/schemas"
        elementFormDefault="qualified">

    <xsd:simpleType name="CCC">
        <xsd:restriction base="ak:GGG">
            <xsd:minLength value = "4" fixed = "true" />
        </xsd:restriction>
    </xsd:simpleType>
    <!-- This seems wrong, it should be GGG, not string -->
    <!--    // CCC ...-->
    <!--    type CCC string-->

    <xsd:simpleType name="GGG">
        <xsd:annotation><xsd:documentation>FFF</xsd:documentation></xsd:annotation>
        <xsd:restriction base="xsd:string"/>
    </xsd:simpleType>
    <!--    // GGG is FFF-->
    <!--    type GGG string-->

</xsd:schema>

Or this?

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        targetNamespace="http://example.com/schemas"
        xmlns:ak="http://example.com/schemas"
        elementFormDefault="qualified">

    <xsd:element name="CCC">
        <xsd:simpleType>
            <xsd:restriction base="ak:GGG">
            </xsd:restriction>
        </xsd:simpleType>
        <!-- This seems wrong, it should be GGG, not string -->
        <!--        // AkGGG ...-->
        <!--        type AkGGG string-->
    </xsd:element>
    <!-- This seems very wrong, it should be a struct -->
    <!--    // CCC is FFF-->
    <!--    type CCC *CCC-->

    <xsd:simpleType name="GGG">
        <xsd:annotation><xsd:documentation>FFF</xsd:documentation></xsd:annotation>
        <xsd:restriction base="xsd:string"/>
    </xsd:simpleType>
    <!--    // GGG ...-->
    <!--    type GGG string-->

</xsd:schema>

@Jabst
Copy link

Jabst commented Sep 23, 2024

I have the same issue. Simple Types are not being created

@Jabst
Copy link

Jabst commented Sep 23, 2024

While trying to comprehend what is the cause, I think there is an issue when we find a xsd:simpleType without a Name attribute it causes the SimpleType to not work.

I have checked the resulting .SimpleType() in the genGo.go and the list is empty

@Jabst
Copy link

Jabst commented Sep 23, 2024

I think the implementation relies heavily on state mutations, leading to big interdependencies and hard to solve edge cases. In my XSD I have a complexType, a sequence, an element(with no type attribute), a simpleType, a restriction and two enumerations all nested in that order.

After the complexType "ends" there will be simpleTypes that define some of the elements i have inside the previous complexType.

The issue is that when I check the implementation, if the SimpleType Length and the Element length are greater than zero, I will .Pop() the SimpleType and then once I reach the SimpleType closing tag, I already did a .Pop() on the SimpleType so that simpleType that is outside will never be added to the opt.ProtoTree. Is this a wanted behaviour? It feels to me that the opt.Element should be empty after I processed the closing tag for complexType, therefore not doing the .Pop()

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

2 participants