forked from soapteam/soapfish
-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO
61 lines (51 loc) · 3 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
TODO
====
This project is very, very promising:
- It is focussed on XML and SOAP/WSDL without any compromise. In an ideal world
soapbox works with each and every syntax allowed by these technologies.
- It allows you to have a representation of arbitrary XML including support
for XSD. Parse any XML described by a schema into a nice class-based tree
(and the other way round: serialization is possible as well).
- Because soapbox supports only SOAP and no other remoting protocol (e.g.
ReST-style APIs with JSON) the API is not tied to the lowest common
denominator. You should be able implement any given WSDL.
Unfortunately we're not there yet.
This is a typical open source software and XML/SOAP is usually not perceived
as a fun project. So various users added some smaller features which they
needed but typically there are many incomplete implementations above the very
basic layer (the object model to represent XML/XSD programmatically).
On the upside that means there are a lot of ways to improve the code and your
contribution and make a big difference.
Here some bigger areas which need work:
- much more comprehensive unit tests
- SOAP support for web frameworks other than Django (Pyramid already works
with the new SOAPDispatcher class)
- XSD schema generation (object graph to XSD file) has most of its logic in a
very complex Jinja2 template which shows it limits. For example features like
named xs:Elements with embedded anonymous ComplexTypes can not be serialized
to XSD currently.
However the code internally assumes that the class tree and the XSD
representation contain the same information so this can lead to bugs.
- The XSD mapping is currently incomplete: Some types in schemas are not
implemented at all (e.g. xs:date, xs:gYearMonth). Other types might not be
parsed/serialized correctly. Also references to xs:elements are pretty
incomplete right now.
- Generated code (e.g. WSDL handling or XSD mapping) usually has some syntax
errors. Some of them are fixable on their own but often this is because of
other missing features (see above). The output should be usable as
scaffolding though.
- Convert the ad-hoc fork to real project with its own name, website and docs
Don't worry if the items on the list above seem to big for you. Just start out
with something small, write tests and contribute them. Even a small (failing)
unit test which demonstrates a current shortcoming is great.
You might also check out current skipped unit tests which usually represent
missing functionality (though these might not be ideal beginner projects - if
they were trivial to implement I would have done that already).
All these shortcomings and limitations exist only because of the lack of
time and/or awareness about certain XSD features. The goal of this library is
to fully implement XSD schemas and potentially SOAP/WSDL so patches (with tests)
are always welcome.
OTHER TODOS
============
- Fix circular dependency of generated schema classes.
See the **TODO** markers in ``soapbox/*.py`` for a complete list.