rslib-talk

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

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

Hello,

First of all, I want to thank the RSL developer(s) for the work they've
done.  I've had problems with other web services libraries, like SOAPpy,
which RSL seems to handle just fine.  Keep up the good work!

I'm trying to call the web service described by
https://voltage-pp-0000.poc5.vspilot.org/vibesimple/wsdl.  I'm using RSL
0.2.1 with the following code to invoke the ProtectCreditCardNumber
function:


import rsl.wsdl.wsdl

wsdl_url = "https://voltage-pp-0000.poc5.vspilot.org/vibesimple/wsdl"
wsdl = rsl.wsdl.wsdl.loadWSDL(wsdl_url)
proxy = wsdl.getProxy()

proxy.ProtectCreditCardNumber("123456789", "user", None, "UserPassword", \
"password")

 When I run this, however, I get the following exception:

 KeyError: 'Type token in namespace http://www.w3.org/2001/XMLSchema not
found'

I believe this is because of the 4th parameter.  It's type, AuthMethod, is
defined in the WSDL as follows:

<xsd:simpleType name="AuthMethod">
  <xsd:restriction base="xsd:token">
    <xsd:enumeration value="UserPassword"/>
    <xsd:enumeration value="SharedSecret"/>
    <xsd:enumeration value="Certificate"/>
    <xsd:enumeration value="AuthToken_HMAC_SHA1"/>
  </xsd:restriction>
</xsd:simpleType>

Am I doing something wrong, or is this a bug/limitation in RSL?

The exception stacktrace is as follows:

Traceback (most recent call last):
  File "protectcc_example.py", line 8, in <module>
    print proxy.ProtectCreditCardNumber("123456789", "user", None,
"UserPassword", "password")
  File "build/bdist.linux-x86_64/egg/rsl/soap11/proxy.py", line 109, in
__call__
  File "build/bdist.linux-x86_64/egg/rsl/soap11/proxy.py", line 130, in
serialize
  File "build/bdist.linux-x86_64/egg/rsl/soap11/serializer.py", line 125, in
serialize
  File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line 67, in
serialize
  File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line 129, in
serialize
  File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line 199, in
_serialize
  File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line 169, in
_serialize
  File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line 156, in
_serialize
  File "build/bdist.linux-x86_64/egg/rsl/xsd/component.py", line 189, in
encode
  File "build/bdist.linux-x86_64/egg/rsl/xsd/component.py", line 275, in
encode
  File "build/bdist.linux-x86_64/egg/rsl/xsd/component.py", line 247, in
_getbasecontent
  File "build/bdist.linux-x86_64/egg/rsl/xsd/schema.py", line 248, in
getType
KeyError: 'Type token in namespace http://www.w3.org/2001/XMLSchema not
found'


Thanks,

Nathan Davis

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

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

Hello,

thanks for that and great to hear, that the library is also useful for  
others.

I am currently a bit busy, but I will definitely have a closer look at  
your problem later today or tomorrow.

However, as of a quick look I would say I forgot to register the  
xsd:token type.

You can try to fix it in the rsl.xsd package the following way:
    in rsl/xsd/factories.py int the method: createXSD01Schema add the  
line:
       xsd.types["token"] = AnySimpleType("token", xsd)

While I can't guarantee that this will work, I think it should do it.

As mentioned above, I'll do a new release today or tomorrow after  
running the test-suite with this change.

As a note: Type restrictions based on xsd:enumeration are currently  
ignored by rsl.xsd ... You can definitely work with it, but you have  
to care yourself about suppllying correct values to this attribute.

Regards,

Gerhard

On 26/08/2009, at 12:08 PM, Nathan Davis wrote:

> Hello,
>
> First of all, I want to thank the RSL developer(s) for the work  
> they've done.  I've had problems with other web services libraries,  
> like SOAPpy, which RSL seems to handle just fine.  Keep up the good  
> work!
>
> I'm trying to call the web service described by https://voltage-pp-0000.poc5.vspilot.org/vibesimple/wsdl 
> .  I'm using RSL 0.2.1 with the following code to invoke the  
> ProtectCreditCardNumber function:
>
> import rsl.wsdl.wsdl
>
> wsdl_url = "https://voltage-pp-0000.poc5.vspilot.org/vibesimple/wsdl"
> wsdl = rsl.wsdl.wsdl.loadWSDL(wsdl_url)
> proxy = wsdl.getProxy()
>
> proxy.ProtectCreditCardNumber("123456789", "user", None,  
> "UserPassword", \
> "password")
>  When I run this, however, I get the following exception:
>  KeyError: 'Type token in namespace http://www.w3.org/2001/XMLSchema  
> not found'
> I believe this is because of the 4th parameter.  It's type,  
> AuthMethod, is defined in the WSDL as follows:
> <xsd:simpleType name="AuthMethod">
>   <xsd:restriction base="xsd:token">
>     <xsd:enumeration value="UserPassword"/>
>     <xsd:enumeration value="SharedSecret"/>
>     <xsd:enumeration value="Certificate"/>
>     <xsd:enumeration value="AuthToken_HMAC_SHA1"/>
>   </xsd:restriction>
> </xsd:simpleType>
> Am I doing something wrong, or is this a bug/limitation in RSL?
>
> The exception stacktrace is as follows:
> Traceback (most recent call last):
>   File "protectcc_example.py", line 8, in <module>
>     print proxy.ProtectCreditCardNumber("123456789", "user", None,  
> "UserPassword", "password")
>   File "build/bdist.linux-x86_64/egg/rsl/soap11/proxy.py", line 109,  
> in __call__
>   File "build/bdist.linux-x86_64/egg/rsl/soap11/proxy.py", line 130,  
> in serialize
>   File "build/bdist.linux-x86_64/egg/rsl/soap11/serializer.py", line  
> 125, in serialize
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line  
> 67, in serialize
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line  
> 129, in serialize
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line  
> 199, in _serialize
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line  
> 169, in _serialize
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line  
> 156, in _serialize
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/component.py", line  
> 189, in encode
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/component.py", line  
> 275, in encode
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/component.py", line  
> 247, in _getbasecontent
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/schema.py", line 248,  
> in getType
> KeyError: 'Type token in namespace http://www.w3.org/2001/XMLSchema  
> not found'
>
> Thanks,
>
> Nathan Davis
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july_______________________________________________
> Rslib-talk mailing list
> Rsl...@li...
> https://lists.sourceforge.net/lists/listinfo/rslib-talk

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

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

On Tue, Aug 25, 2009 at 10:45 PM, Gerhard Weis <ger...@gm...> wrote:

> Hello,
>

Hi, Gerhard,


>
> thanks for that and great to hear, that the library is also useful for
> others.
>
> I am currently a bit busy, but I will definitely have a closer look at your
> problem later today or tomorrow.
>
> However, as of a quick look I would say I forgot to register the xsd:token
> type.
>
> You can try to fix it in the rsl.xsd package the following way:
>   in rsl/xsd/factories.py int the method: createXSD01Schema add the line:
>      xsd.types["token"] = AnySimpleType("token", xsd)
>
> While I can't guarantee that this will work, I think it should do it.
>

That did it!  I can't say I called the service successfully, but at least
I'm past that error.  Now it's just a matter of figuring out how to form the
other parameters to make the server happy -- fortunately it provides fairly
descriptive error strings.

Would a complete fix also include adding the same line to createCSD99Schema?


>
> As mentioned above, I'll do a new release today or tomorrow after running
> the test-suite with this change.
>

Thanks.  I'm doing for a client, so that would be very helpful.

Incidently, would it be possible to monkey-patch this -- for example, if
another type was missing or (heaven forbid) someone referenced a
non-standard xsd type in their WSDL?


>
> As a note: Type restrictions based on xsd:enumeration are currently ignored
> by rsl.xsd ... You can definitely work with it, but you have to care
> yourself about suppllying correct values to this attribute.
>

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.

Thank you so much,

Nathan Davis

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

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

Hi Nathan,

I oversaw one of your questions :)

>
> Incidently, would it be possible to monkey-patch this -- for  
> example, if another type was missing or (heaven forbid) someone  
> referenced a non-standard xsd type in their WSDL?

Normally I'd consider a service with such a WSDL as broken,  
unfortunately there are a lot of broken WSDLs out there.

I think the simples thing to do in such a case is to add a similar  
definition for such types directly into the xsd-instance just like you  
did it with xsd:token.
(just choose or implement a suitable alternative for AnySimpleType if  
you need something different.)

The standard xsd-schema should be accessible via the global schema  
manager (see rsl/xsd/manager.py and somewhere should be code how to  
access it, but as a quick fix you can access it directly there.)

from rsl.xsd.manager import GLOBALSCHEMAMANAGER

xsd = GLOBALSCHEMAMANAGER.getSchema('http://www.w3.org/2001/XMLSchema')
xsd.types['.....'] = AnySimpleType(......)


the thing with accessing the GLOBALSCHEMAMANAGER directly will also go  
away in rsl.xsd >= 0.3 (zope's AdapterFactory will make this a lot  
easier)

cheers,

Gerhard

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

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

Hi Nathan,


> That did it!  I can't say I called the service successfully, but at  
> least I'm past that error.  Now it's just a matter of figuring out  
> how to form the other parameters to make the server happy --  
> fortunately it provides fairly descriptive error strings.

so far good to hear :)

>
> Would a complete fix also include adding the same line to  
> createCSD99Schema?

Yes, but I have not seen a service which uses the old xml-schema name- 
space for a long time. Basically it is just there to satisfy my tests.

> Thanks.  I'm doing for a client, so that would be very helpful.

You're welcome.

>
> Incidently, would it be possible to monkey-patch this -- for  
> example, if another type was missing or (heaven forbid) someone  
> referenced a non-standard xsd type in their WSDL?

I'll go through the list of xsd-types and will add them. Derived types  
from other name-spaces should be created automatically. It's just the  
the types defined in xml-schema which need to be registered there. I  
know it is not a very clean solution, but as xsd is defined by itself  
I could not think of an easy solution to overcome this issue.

>
> 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).....
An additional goal is that custom python classes should be completely  
unaware of such a transformation makeing it easier to include third  
party code. (that's why I am using zope.interface and adaptation).
Furthermore the br-03.dev implementation supports a lot more features  
of xml-schema, like xsd:groups etc. It also does a better job in type  
conversion regarding string formatting for the xml-representation and  
respects various xsd:facets defined in an xml-schema.

Unfortunately I have not had much time lately to work on it, but I  
think it is rather close to be finished for a first release. (At least  
it should provide the same amount of functionality as the 0.2.x  
release series before I make a release).

I also plan to refactor all the other rsl.xxx parts to use  
zope.interface and adaption, which should make it much easier to  
customise various aspect of the library.

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

Cheers,

Gerhard

Don't hesitate to ask if you have any further problems or suggestions :)

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

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

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

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

Hi,

just to let you know, I uploaded a new rsl.xsd package to pypi.

I did just a quick fix for all xml-schema data types. The user itself  
has to take care about the actual formatting and type constraints. All  
new integer-based types are mapped to python int and all other new  
types are mapped to python strings (or better unicode strings).

This means if you are going to use xsd:time (which is new in this  
release) you have to do the iso-formatting/parsing for this data type  
yourself. Sorry for that, but the whole code should no longer fail  
reading any valid xsd :)

cheers,

Gerhard