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
Creating a schema from WSDL/XSD which have xsd:restriction raised an error. Would be good to have that fixed by simply ignoring the restrictions in a first step. Some cases perhaps could also be mapped to enum later.
XSD-Doc: https://www.w3schools.com/xml/schema_facets.asp
Should use the base as type for the field.
Map to enum seems plausible.
All other possible restrictions don't have a proper correspondence in GraphQL (AFAIS). But we could put them in the comment for the field.
- make apis provided by the generated schema as stable as possible (introduce namespaces for types, don't return only the first operation output message part, fallback to GraphQLJSON on generation errors and incompatible xsd to preserve a working (but partly untyped) schema).
- Set a more versatile foundation for additional xsd features which can be implemented later without breaking changes.
- Fix errors around the type resolution in different namespaces.
- Remove the usage of node-soap's service descriptions because they are incomplete. Unfortunately node-soap seems to rely on them too which leads to some bugs.
- Remove specs which don't work anymore because of removed WSDL sources
Fixes#16 and partially #17 and #18
Creating a schema from WSDL/XSD which have xsd:restriction raised an error. Would be good to have that fixed by simply ignoring the restrictions in a first step. Some cases perhaps could also be mapped to enum later.
Example:
The text was updated successfully, but these errors were encountered: