Custom types are not being recognized/ignored #564
Comments
|
Hi @FirefoxMetzger only complex types and elements are generated, everything else with the exception of enumerations are flattened. <?xml version='1.0' encoding='UTF-8'?>
<xsd:schema xmlns:xsd='http://www.w3.org/2001/XMLSchema'>
<xsd:simpleType name="vector3">
<xsd:restriction base="xsd:string">
<xsd:pattern value="(\s*(-|\+)?(\d+(\.\d*)?|\.\d+|\d+\.\d+[eE][-\+]?[0-9]+)\s+){2}((-|\+)?(\d+(\.\d*)?|\.\d+|\d+\.\d+[eE][-\+]?[0-9]+))\s*"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="quaternion">
<xsd:restriction base="xsd:string">
<xsd:pattern value="(\s*(-|\+)?(\d+(\.\d*)?|\.\d+|\d+\.\d+[eE][-\+]?[0-9]+)\s+){3}((-|\+)?(\d+(\.\d*)?|\.\d+|\d+\.\d+[eE][-\+]?[0-9]+))\s*"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:element name="First" type="quaternion" />
<xsd:complexType name="Second">
<xsd:sequence>
<xsd:element name="vector3" type="vector3" />
<xsd:element name="quaternion" type="quaternion" />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>@dataclass
class First:
value: Optional[str] = field(
default=None,
metadata={
"required": True,
"pattern": r"(\s*(-|\+)?(\d+(\.\d*)?|\.\d+|\d+\.\d+[eE][-\+]?[0-9]+)\s+){3}((-|\+)?(\d+(\.\d*)?|\.\d+|\d+\.\d+[eE][-\+]?[0-9]+))\s*",
}
)
@dataclass
class Second:
vector3: Optional[str] = field(
default=None,
metadata={
"type": "Element",
"namespace": "",
"required": True,
"pattern": r"(\s*(-|\+)?(\d+(\.\d*)?|\.\d+|\d+\.\d+[eE][-\+]?[0-9]+)\s+){2}((-|\+)?(\d+(\.\d*)?|\.\d+|\d+\.\d+[eE][-\+]?[0-9]+))\s*",
}
)
quaternion: Optional[str] = field(
default=None,
metadata={
"type": "Element",
"namespace": "",
"required": True,
"pattern": r"(\s*(-|\+)?(\d+(\.\d*)?|\.\d+|\d+\.\d+[eE][-\+]?[0-9]+)\s+){3}((-|\+)?(\d+(\.\d*)?|\.\d+|\d+\.\d+[eE][-\+]?[0-9]+))\s*",
}
) |
Thank you for this pointer, it got me on the right track. I tripped over the error messages stating that the element with custom type was not found, and - after I manually added it - the next element with custom type was not found, and so on. With your pointer in mind, I checked again and found that other elements (with basic types) were missing, too. After digging through the schema, I found a bug over in SDFormat that causes all of this, because the generated xsd files are faulty ( With this in mind, I have two more questions: How are include tags handled if the resource is not found? I have xsdata warnings of the form Second, is there a way to make xsdata warn/abort in the event of a naming conflict in the schema? Thanks to the bug in SDFormat I get .xsd of the form ...
<xsd:include schemaLocation='model.xsd'/> <!-- defines <xsd:element name='model'> -->
<xsd:include schemaLocation='model_state.xsd'/> <!-- defines <xsd:element name='model'> -->
...which is expanded into a naming conflict: ...
<xsd:element name='model'> ... </xsd:element>
<xsd:element name='model'> ... </xsd:element>
...xsdata never creates the bindings for |
|
The generator is very lenient, with missing types or imports, it's actually accepted in the specification that types can be "absent", in these cases the generator is substituting the missing types with xs:anySimpleType or with xs:string depending the case. The generator emits warnings on these cases (#1, #2), but they are lost in the whole output, but I am planning like a warnings summary like pytest (#534) Naming conflicts are also accepted in the specification but the handling depends on the case, there are various scenarios
xsdata/xsdata/codegen/validator.py Lines 23 to 43 in 6fba838 |
Nice. That explains what's happening on my end. The schema server is outdated and doesn't have certain files; xsdata ignores these includes and correctly emits warnings. At the same time, any missing elements/types are defined by local copies of what the server should have. I call
Actually the last one prevails. Without knowing the codebase, I guess existing elements are stored in a |
|
xsdata/xsdata/codegen/container.py Lines 158 to 160 in 6fba838 Perhaps this is the spot where naming conflicts are silently resolved/eaten? |
|
Thanks for the suggestion @FirefoxMetzger xsdata xsdata-w3c-tests/w3c/msData/particles/particlesJs001.xsd
Parsing schema particlesJs001.xsd
Parsing schema particlesJs001.imp
Compiling schema particlesJs001.imp
Builder: 4 main and 0 inner classes
Compiling schema particlesJs001.xsd
Builder: 3 main and 0 inner classes
Analyzer input: 7 main and 0 inner classes
warning: Duplicate types (2) found: {http://xsdtesting}B, will keep the last defined!
Analyzer output: 6 main and 0 inner classes
Generating package: init
Generating package: generated.particles_js001
Generating package: generated.particles_js001_imp |
|
Wow, so quick! Thank you for looking into this so fast. One suggestion:
Should this be rephrased to |
Let me first apologize in advance in case this issue is more of a support request than a bug. I've been trying to figure out how this works, and perhaps I'm just doing things wrong and everything is fine. In this case - depending on the solution - I might be able to turn this issue into a doc PR 🚀
I'm trying to generate bindings for SDFormat using the CLI tool. SDFormat is XML but has some quirks to it. For example, custom types based on
xsd:stringand a regex. In my case, they are defined in atypes.xsd(found here). The problem is that, when I generate the stubs, any element that is of such a custom type does not show up in the generated bindings and I can't figure out why. I also don't get any warning about missing/dropped/ignored elements. My hunch is that this is a severe case of user error because I am a first-time user of xsdata.I can provide a MVE if it helps, once I find a place to upload the .xsd files; they are quite interdependent. Unfortunately, they are not part of the official SDFormat repo, because it is actually a C++ project, and .xsd is generated from templates during preprocessing/building with CMake. Theoretically, there is a SDFormat schema server that serves .xsd and that is being referred to in the generated files, but that one is actually outdated and doesn't seem to be actively maintained :( Also, iirc, xsdata doesn't fetch includes from remote, so this won't make much of a difference.
In the meantime, I can share two representative files; maybe that is already enough to identify the problem. In
world.xsdthe fieldsgravityandmagnetic_field(among others) are the ones that don't show up in the bindings.types.xsd
world.xsd
Any help or pointers are highly appreciated 💯
The text was updated successfully, but these errors were encountered: