The driving environment for PyXB's development is a community of
engineers who use Python to compose applications from existing
capabilities in multiple languages (primarily Fortran and C++). The
execution model and development environment of Java do not suit their
culture. They are being asked to publish interfaces to their systems in
an enterprise-wide service-oriented architecture, and to make use of
services provided by others. The environment mandates an
industry-supported standard for interfaces that can be accessed through
a machine-readable service definition, rather than a vendor-provided
language-specific library. Java and C++ both have tools that support
XML as a solution for this problem; Python has historically been less
mature.
When operating with XML-based services that define their interfaces with
schema, static bindings simplify both service provider and client. In
some cases it may be easy in Python to consume a service's XML without a
binding, but to produce a document that is certain to conform to the
service requirements can be quite a bit more effort. This is especially
true for complex descriptions like the Geography Markup Language.
For these situations, my hope is that PyXB will help eliminate the overt
intrusion of XML into the code of an end user who really only wants to
use (or provide) the service. PyXB is only appropriate where an XML
schema is already available or useful for other reasons. That the
current version nearly insists upon doing validation of input and output
will make it unsuitable for some of those cases, though that's an issue
that would be straightforward to address.
Peter
_______________________________________________
XML-SIG maillist - XML...@python.org
http://mail.python.org/mailman/listinfo/xml-sig