Re: [Rslib-talk] Type token in namespace http://www.w3.org/2001/XMLSchema not found

[Nathan D. <dav...@gm...>]

On Wed, Aug 26, 2009 at 12:05 AM, Gerhard Weis <ger...@gm...> wrote:

>
>> I'm curious what your plans are for expanding this in the future -- or,
>> actually, the type system in general.  It would be nice, for example, to be
>> able to work with types defined in the schema as python classes.  I'd like
>> to get your thoughts on the feasibility of dynamically generating python
>> classes from schemas.
>>
>
> If you are really curious on reading a bit of python code you can have a
> look into the source-repository (http://hg.proclos.com/rslib) or
> specifically for the rsl.xsd package: http://hg.proclos.com/rslib/rsl.xsd/ ...
> I did already quite a bit of work on the br-0.3-dev branch. The idea behind
> is, to use parts of the zope component architecture (I think this will be
> just the zope.interface package) to make the whole type-system pluggable.
>
> The main goals of this branch are to allow custom python classes to be
> used, with rsl.xsd. Basically you'll need to register an adapter which does
> a simple transformation from a python object to an  representation which
> rsl.xsd understands (currently simple dictionaries).....
>

Yes, that sounds useful as well.


>
> Regarding dynamically generated python classes:
>
> Personally I am not a fan of dynamically generated classes. However, the
> rsl.xsd 0.3 branch should make it rather easy to add a separate package
> supporting this use case, or generate python code or whatever. For instance
> I could imagine to add an adapter for various xsd:types which generates
> classes on the fly. So I won't ignore dynamic class creation/code creation,
> but I think I won't create such a package by myself. If someone wants to do
> it, I can definitely provide help on how to use rsl.xsd, but my main
> priority is to move the whole rsl-stuff up to the rsl.xsd 0.3 branch. And
> stabilise the whole thing. Another thing which I want to do before I think
> of class/code creation, is to add support for WSDL2 and some additional WS-X
> standards like WS-Addressing and WS-Security etc....
>

I can't say I'm a huge fan of dynamically generated classes, but I believe
they have their uses.  If you're going to generate the class from another
source anyway, I think it makes sense to do it dynamically in a dynamic
language.  They key (and sometimes the difficulty) is to generate the
classes early enough so they are available when they're needed.

What I'm thinking is something like generating a class, and attatching it to
the wsdl/proxy object.  So, for example, you could do something like:

> foo = proxy.types.Foo()
> foo.bar = 'bar'
> foo.baz = 123
>
where, for instance Foo is a complex type containing members bar (a string)
and baz (and integer).

I'm not a SOAP/WSDL expert, but does WSDL separate interface from the
endpoint?  In other words, if I have to services that are identical except
for URL, is there a way for each service to say "hey, I'm just a service
that implements interface ABC?"  If so, then it would make most sense to
associate the classes with that.

Anyway, I know you're busy, and it's not really that important to me.  But,
in a perfect world, I'd envision something like that.

Take Care,

Nathan Davis