: WSDL Generated Does Not Validate

Edit report at 
http://pecl.php.net/bugs/bug.php?id=11004&edit=1

 ID:               11004
 Updated by:       mfpphp.net
 Reported By:      michael dot caplan at henryschein dot
com
 Status:           Feedback
 Id:               11004
 Type:             Bug
 Package:          SCA_SDO
 Operating System: CentOS 4
 PHP Version:      5.2.1
 New Comment:

I just raised a defect report against the underlying C++
code that is
in the sdo extension. 



ht
tps://issues.apache.org/jira/browse/TUSCANY-1297


Previous Comments:
------------------------------------------------------------
------------

[2007-05-23 11:47:35] mfp at php dot net

Can you say why the wsdl does not validate? Is it the
xsi:type 
attributes?

------------------------------------------------------------
------------

[2007-05-17 09:03:12] mfp at php dot net

I just realised that when I said 'the second binding element
(the one
in the tns3 namespace...' I meant the second _operation_
element (i.e.
the one with the soapAction). Sorry about that.

------------------------------------------------------------
------------

[2007-05-17 08:32:13] mfp at php dot net

Mike, this is overkill. We think that the second binding
element (the
one in the tns3 namespace, which is really the soap
namespace) is
required (we see lots of examples of this for web services
on
www.xmethods.net) and we are even more sure that we must
have the second
binding element. 



Are you able to get any more information about why the wsdl
does not
validate? I suspect that it might be to do with the xsi:type
elements.
Could you try just taking out those elements? If that is the
problem we
could do a quick fix where we suppress them. In fact we do
not want SDO
to generate them at all, and it would be useful for us to
know that they
cause validation errors for you. After a quick fix, I could
raise a
defect report on the SDO code.

------------------------------------------------------------
------------

[2007-05-10 15:34:11] michael dot caplan at henryschein dot
com

Description:
------------
My WSDL generated does not validate (ran against the oXygen
editor and
Mindreef SOAPscope).  The bindings elements appears to be
adding bogus
child elements (operation contains a child of operation
& binding
contains a child of binding).





The following diff fixed these issues:





Index:
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDe
scriptionGenerator.php

============================================================
=======

---
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDe
scriptionGenerator.php	(revision
195)

+++
Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDe
scriptionGenerator.php	(working
copy)

 -120,18
+120,10 

             $binding                     =
$wsdl->createDataObject('binding');

             $binding->name                 =
"{$class_name}Binding";

             $binding->type                 =
"{$wsdl->targetNamespace}#{$class_name}PortType"
;;

-            $soap_binding                 =
$xmldas->createDataObject(self::SOAP_NAMESPACE,
'tBinding');

-            $soap_binding->style         = 'document';

-            $soap_binding->transport     =
'http://schemas.x
mlsoap.org/soap/http';

-            $binding->binding             =
$soap_binding;

             foreach ($service_desc->operations as
$op_name => $params)
{

                 $binding_operation             =
$binding->createDataObject('operation');

                 $binding_operation->name     =
$op_name;

 

-                $soap_operation             =
$xmldas->createDataObject(self::SOAP_NAMESPACE,
'tOperation');

-                $soap_operation->soapAction =
"";

-                $binding_operation->operation    =
$soap_operation;

-

                 $bo_input                     =
$binding_operation->createDataObject('input');

                 $soap_body                     =
$xmldas->createDataObject(self::SOAP_NAMESPACE,
'tBody');

                 $bo_input->body             =
$soap_body;



Expected result:
----------------
  <binding
name="Labnet_API_LabnetOnline_001_ImplementationBinding
"
type="tns2:Labnet_API_LabnetOnline_001_ImplementationPo
rtType">

    <operation name="getRestorations">

      <input>

        <tns3:body xsi:type="tns3:tBody"
use="literal"/>

      </input>

      <output>

        <tns3:body xsi:type="tns3:tBody"
use="literal"/>

      </output>

    </operation>

  </binding>

Actual result:
--------------
<binding
name="Labnet_API_LabnetOnline_001_ImplementationBinding
"
type="tns2:Labnet_API_LabnetOnline_001_ImplementationPo
rtType">

    <operation name="getRestorations">

      <input>

        <tns3:body xsi:type="tns3:tBody"
use="literal"/>

      </input>

      <output>

        <tns3:body xsi:type="tns3:tBody"
use="literal"/>

      </output>



      <tns3:operation
xsi:type="tns3:tOperation"
soapAction=""/>

    </operation>

<tns3:binding xsi:type="tns3:tBinding"
transport="http://sch
emas.xmlsoap.org/soap/http"
style="document"/>

  </binding>

------------------------------------------------------------
------------


-- 
Edit this bug report at 
http://pecl.php.net/bugs/bug.php?id=11004&edit=1


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "phpsoa" group.
To post to this group, send email to phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Matthew, thanks for helping administer the SDO defects. A
few points 
of process:

a) in Tuscany-land, the XML support is not a DAS, it's core
code (the 
XMLHelper). I realise why it's tempting to assign the jira
to "C++ DAS", 
but those are the people working on a C++ Relational DAS.
The component 
you want is "C++ SDO". I've transferred this one
for you.

b) When a defect is assigned to Tuscany, we assign it to
"tuscany". This 
one was left in feedback state, which means that we're
waiting for the 
originator to do something. We also add a link to the
Tuscany defect - 
which you did - but it wasn't clickable because the peclweb
code only 
does that for http, not https (doh). So I added another
one.

c) Since I last overhauled the defects, I have been
operating a more 
test-driven development process. Sometimes these Tuscany
defects take a 
long time to fix, and it's not always easy to recreate the
original 
problem when you've forgotten the details. Plus we need to
keep building 
a good regression suite for real problems that people have
encountered. 
So part of the act of transferring a defect should be to
create a 
testcase while the details are clear in your mind, and add
it to the 
test suite, skipped so that it doesn't make the test suite
fail. See, 
for example, 
http://cvs.php.net
/viewvc.cgi/pecl/sdo/tests/SDO/phpt/bug8694.phpt?view=markup
&sortby=date
though of course you may choose a phpunit test if you
prefer. Please 
would you add a test for this bug too?


mfpphp.net wrote:
> Edit report at 
http://pecl.php.net/bugs/bug.php?id=11004&edit=1
> 
>  ID:               11004
>  Updated by:       mfpphp.net
>  Reported By:      michael dot caplan at henryschein
dot com
>  Status:           Feedback
>  Id:               11004
>  Type:             Bug
>  Package:          SCA_SDO
>  Operating System: CentOS 4
>  PHP Version:      5.2.1
>  New Comment:
> 
> I just raised a defect report against the underlying
C++ code that is
> in the sdo extension. 
> 
> 
> 
> ht
tps://issues.apache.org/jira/browse/TUSCANY-1297


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "phpsoa" group.
To post to this group, send email to phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Matthew, thanks for helping administer the SDO defects. A
few points 
of process:

a) in Tuscany-land, the XML support is not a DAS, it's core
code (the 
XMLHelper). I realise why it's tempting to assign the jira
to "C++ DAS", 
but those are the people working on a C++ Relational DAS.
The component 
you want is "C++ SDO". I've transferred this one
for you.

b) When a defect is assigned to Tuscany, we assign it to
"tuscany". This 
one was left in feedback state, which means that we're
waiting for the 
originator to do something. We also add a link to the
Tuscany defect - 
which you did - but it wasn't clickable because the peclweb
code only 
does that for http, not https (doh). So I added another
one.

c) Since I last overhauled the defects, I have been
operating a more 
test-driven development process. Sometimes these Tuscany
defects take a 
long time to fix, and it's not always easy to recreate the
original 
problem when you've forgotten the details. Plus we need to
keep building 
a good regression suite for real problems that people have
encountered. 
So part of the act of transferring a defect should be to
create a 
testcase while the details are clear in your mind, and add
it to the 
test suite, skipped so that it doesn't make the test suite
fail. See, 
for example, 
http://cvs.php.net
/viewvc.cgi/pecl/sdo/tests/SDO/phpt/bug8694.phpt?view=markup
&sortby=date
though of course you may choose a phpunit test if you
prefer. Please 
would you add a test for this bug too?

mfpphp.net wrote:
> Edit report at 
http://pecl.php.net/bugs/bug.php?id=11004&edit=1
> 
>  ID:               11004
>  Updated by:       mfpphp.net
>  Reported By:      michael dot caplan at henryschein
dot com
>  Status:           Feedback
>  Id:               11004
>  Type:             Bug
>  Package:          SCA_SDO
>  Operating System: CentOS 4
>  PHP Version:      5.2.1
>  New Comment:
> 
> I just raised a defect report against the underlying
C++ code that is
> in the sdo extension. 
> 
> 
> 
> ht
tps://issues.apache.org/jira/browse/TUSCANY-1297


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "phpsoa" group.
To post to this group, send email to phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Matthew, thanks for helping administer the SDO defects. A
few points 
of process:

a) in Tuscany-land, the XML support is not a DAS, it's core
code (the 
XMLHelper). I realise why it's tempting to assign the jira
to "C++ DAS", 
but those are the people working on a C++ Relational DAS.
The component 
you want is "C++ SDO". I've transferred this one
for you.

b) When a defect is assigned to Tuscany, we assign it to
"tuscany". This 
one was left in feedback state, which means that we're
waiting for the 
originator to do something. We also add a link to the
Tuscany defect - 
which you did - but it wasn't clickable because the peclweb
code only 
does that for http, not https (doh). So I added another
one.

c) Since I last overhauled the defects, I have been
operating a more 
test-driven development process. Sometimes these Tuscany
defects take a 
long time to fix, and it's not always easy to recreate the
original 
problem when you've forgotten the details. Plus we need to
keep building 
a good regression suite for real problems that people have
encountered. 
So part of the act of transferring a defect should be to
create a 
testcase while the details are clear in your mind, and add
it to the 
test suite, skipped so that it doesn't make the test suite
fail. See, 
for example, 
http://cvs.php.net
/viewvc.cgi/pecl/sdo/tests/SDO/phpt/bug8694.phpt?view=markup
&sortby=date
though of course you may choose a phpunit test if you
prefer. Please 
would you add a test for this bug too?

mfpphp.net wrote:
> Edit report at 
http://pecl.php.net/bugs/bug.php?id=11004&edit=1
> 
>  ID:               11004
>  Updated by:       mfpphp.net
>  Reported By:      michael dot caplan at henryschein
dot com
>  Status:           Feedback
>  Id:               11004
>  Type:             Bug
>  Package:          SCA_SDO
>  Operating System: CentOS 4
>  PHP Version:      5.2.1
>  New Comment:
> 
> I just raised a defect report against the underlying
C++ code that is
> in the sdo extension. 
> 
> 
> 
> ht
tps://issues.apache.org/jira/browse/TUSCANY-1297


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "phpsoa" group.
To post to this group, send email to phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---