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

[Gerhard W. <ger...@gm...>]

Hi,

>
> 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.

Yes that definitely makes sense :). (and that's why I am trying to  
keep it in mind.)

>
> 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).

Interesting idea to access the dynamic class via the proxy.

I thought more about attaching it to the schema instance. The schema  
look-up in rsl works upwards in the hierarchy. That means, if you are  
looking for a specific schema-type starting from your WSDL instance,  
the lib tries to find it in the WSDL (which is somewhat like a schema  
manager). If it is not there, it goes up the schema manager hierarchy  
and  looks there, and so on... My idea now was to attach type- 
conversion adapters on the various schema instances . So you can  
override a specific xsd-type for your wsdl, without touching the  
adapters in the hierarchy levels above. Or you can attach adapters  
higher in the hierarchy which allows you to share them between  
instances lower in the hierarchy. This allows having different xsd- 
type python-class association for different xsd/wsdl instances.

I added the schema manager hierarchy, because I wanted to keep various  
well-known xml-schemas just once in memory. Additionally this allows  
also to do configurations or tweaks to these schemas just once. (In  
case this is not useful for a specific use case, it is always possible  
using other root-schema managers than the global one.)

For accessing the definition of a dynamic generated class I had  
something like this in mind:

foo = IDynamicClass(wsdl.getType('<fully qualified xsd-type name>'))()

(I am not sure whether an adaption like that would work or not, but I  
am sure somehow it can be done.)

So you retrieve the xsd-class definition, and the IDynamicClass  
adapter returns the class-definition (or a factory) which you can call  
to generate instances of it. (Or maybe some kind of utility method  
which does the adaption for you, based on a schema instance where you  
start to look for a xsd-type definition and a type name. This would  
then resemble named adapters.)
The point I really like on the adaption stuff is, that it can easily  
be added as additional package without requiring me to include class- 
generation code into the main package. (and maybe forces me to  
maintain this code too :) )

Btw. another Idea I am following in the 0.3 branch is, for complex  
types it may well be useful to re-use class/type associations.
e.g.: if you think of a person, with the attributes name and address.  
name is a simple string and address is another complex type.
A person instance would then reuse the python string-class for it's  
name attribute and maybe another custom address class for it's address  
attribute.
If the address xsd-type is re-used in various other xsd-types than  
person, then all the types could re-use this definition. (At least  
this is how it currently works in the 0.3-branch). How the sub- 
elements and attributes of a xml-person element are associated with  
the Person class is completely up to the type-converter registered on  
the schema-instance.

>
> 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.

Once you've parsed the WSDL, you know should know which endpoint  
offers which interface. WSDL defines the interface separately. The an  
interface is bound to a protocol. (e.g. HTTP, SOAP, etc...), And at  
the end a protocol-binding is associated with an endpoint in a 1:1  
relation. While it is legal to associate various protocol-bindings  
with the same endpoint-url (for each such association there is one  
endpoint definition), I have not seen it yet, that a service offers  
different interfaces for the same endpoint-url.
For sure you can also associate one and the same specific binding with  
multiple endpoints. If both endpoint-urls are in the same WSDL, then  
it is no problem to accept them as equal. If the endpoint's come from  
different WSDL's, then it is not always that easy to consider the  
interfaces associated with the endpoints as equal. (Unfortunately name  
space uniqueness is not always given.)

If you associate the dynamic classes with the proxy then you'll have  
an association of a single endpoint url assigned to the proxy, and the  
python-classes are only valid for this url.
If you do it on the schema in the WSDL, it is for all endpoints in the  
WSDL. (I am not sure which one is better, but maybe it makes sense to  
extend the look-up hierarchy described above to allow both.)

>
> 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.

No worries about that, there is always time for collecting ideas, it  
just may take a while until they are implemented, and my experience  
tells me, the better the plan the less time you'll spend on  
implementing it.

I hope my I was able to explain my Ideas, it is quite some time ago, I  
thought about this stuff.

>
> Take Care,
>
> Nathan Davis