XSD schema imports are not supposed to be transitive. They only allow the
importing schema to reference entities from the imported schema, but do not
include them as their own content. The current XSD schema merging implementation
seems like it's actually including and propagating all the imported content.
- replaced unnecessary list comprehensions with generator expressions to avoid
creating temporary lists
- used standard boolean check when checking for empty containers
- removed a corpse variable assignment
- PEP-8ified comments & made their style consistent
- used double quotes consistently
- removed unnecessary imports
- replaced star imports with explicit ones
Researched into which namespace should be used to qualify SOAP message tags
corresponding to WSDL message parts when using the document/literal binding
style.
- replaced star imports with explicit ones
- improved module, class & method docstrings
- reordered the XSD schema type list alphabetically
- used double quotes consistently
- minor stylistic code changes
TestTransportUsage.test_operation_request_and_reply() test in the test_client.py
module used a WSDL schema that worked fine for that specific test case but did
not exactly match what the developer originally intended. Part of the WSDL's XSD
schema definition got formatted as an embedded Python bytes literal (b"...")
instead of a simple string, resulting in some extra 'b"' & '"' textual XML data.
The extra text data got ignored by suds when parsing that XSD but it was still
not intended to be there in the first place.
Added an assertion to catch cases where such a problem might try and sneak by us
again in the future.
The code checks that the passed namespace parameter is a list or a tuple, but
the raised exception message mentioned only a tuple as a valid namespace value
structure.
Original data accepted only because of extra suds logic to support invalid XSD
schemas but neither was the data actually a valid XSD schema nor is testing that
logic the purpose of the test in question.
Suds now correctly handles twisted use-cases as seen in some M$ web services,
and whose one possible structure has been illustrated by the
test_recursive_WSDL_import() test in the test_client.py test module.
Note that this has nothing to do with recursive XSD schema imports which still
have known issues.
Updated todo list.
- less duplication
- test specific test data now contained in those tests
- test data can now be constructed with custom XSD target namespace
- tests depending on imported & importing WSDL target namespaces now specify
them explicitly
Reduced test data duplication and made the data more parametrizable so we may
use the same data for testing more WSDL import variations.
Moved some more parts of the WSDL import test data into the imported WSDL
schema.
When one WSDL imports another, this does not mean that the components from the
imported WSDL become part of the importing WSDL, but only means that importing
WSDL's components may now reference components from the imported WSDL.
The fact that suds currently imports actual components into the importing WSDL
is in fact a possible bug (unless it is just a part of some internal
implementation detail with no publicly visible side-effects, but even then such
a kludge should be made clearer in code).
Jurko Gospodnetić