I had a look at all these today. The nub of the problem is that both
#11012 and #11004 point at JIRA #1297. I created the confusion in the
first place when I raised Tuscany JIRA 1297 - I raised the original
JIRA with a title that presupposed what the problem was. Really the
problem is that the WSDL will not validate with visual studio,
soapscope, oXygen, or, I now discover, XERCES. There appear to be at
least two problems:

xsi:type upsets visual studio

the order of the <tns3:xxxx elements upsets XERCES

I assume, though can't be sure, because I have not tried them, that
soapscope and oXygen are upset by the second problem.

So there are two problems with the given WSDL; they are described in
pecl 11012 and 11004 respectively;  at the moment both problems are
described in JIRA 1297. I have just put a clarifying append on that
JIRA and will see if they want me to split it into a second JIRA.

And for reference:

pecl 11012 is the one about xsi:type. We could fix this in the SCA PHP
code by hunting down occurences of xsi:type and removing them from the
serialised XML. Or we can wait for Tuscany to fix this one. I last
nagged Tuscany about it a week or so ago.

pecl 11004 is the one about the existence and or order of
<tns3:operation and <tns3:binding. I believe, from my experiment with
XERCES today that it is the order of the elements. The change that
Michael supplied removes these two elements, but I don't think it's OK
to do that - it makes it validate XML-wise, but it's not valid WSDL or
at least the WSDL we want to generate.


You received this message because you are subscribed to the Google Groups 
"phpsoa" group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to