You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org> on 2004/11/11 09:19:25 UTC
[jira] Created: (AXISCPP-257) in WSDLs treated same as
<xsd:all> in WSDLs treated same as <xsd:sequence>
--------------------------------------------------
Key: AXISCPP-257
URL: http://nagoya.apache.org/jira/browse/AXISCPP-257
Project: Axis-C++
Type: Bug
Components: Basic Architecture, WSDL processing
Versions: current (nightly), 1.3 Final
Reporter: Samisa Abeysinghe
>From mailing list:
Samisa->
Can we expect the SOAP message to have the elements in the same order defined by the
WSDL? If yes (I think it is) we are OK. If not we have another bug :(
Adrian Smith ->
If the schema says <xs:sequence> then yes, the order is expected to be
correct, but not if it says <xs:all>
Carsten->
I also looked at <xsd:choice>, which also has arbitrary ordering of a finite choices. \
My impression was that the generated stubs was not able to handle that at all. \
Typically there would be something like a switch for all the possiblities.
What I have seen to deal with cases like this is an intermediate structure between \
parser and interpreting code where it is possible to push back the current element \
back to have some other code handle it.
See the mail thread http://marc.theaimsgroup.com/?t=109902729200001&r=1&w=2 for more information
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: [jira] Created: (AXISCPP-257) in WSDLs treated same as
Posted by ??? <ge...@yahoo.com.cn>.
----- Original Message -----
From: "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>
To: <ax...@ws.apache.org>
Sent: Thursday, November 11, 2004 4:19 PM
Subject: [jira] Created: (AXISCPP-257) <xsd:all> in WSDLs treated same as <xsd:sequence>
> <xsd:all> in WSDLs treated same as <xsd:sequence>
> --------------------------------------------------
>
> Key: AXISCPP-257
> URL: http://nagoya.apache.org/jira/browse/AXISCPP-257
> Project: Axis-C++
> Type: Bug
> Components: Basic Architecture, WSDL processing
> Versions: current (nightly), 1.3 Final
> Reporter: Samisa Abeysinghe
>
>
> From mailing list:
>
> Samisa->
> Can we expect the SOAP message to have the elements in the same order defined by the
> WSDL? If yes (I think it is) we are OK. If not we have another bug :(
>
> Adrian Smith ->
> If the schema says <xs:sequence> then yes, the order is expected to be
> correct, but not if it says <xs:all>
>
> Carsten->
> I also looked at <xsd:choice>, which also has arbitrary ordering of a finite choices. \
> My impression was that the generated stubs was not able to handle that at all. \
> Typically there would be something like a switch for all the possiblities.
> What I have seen to deal with cases like this is an intermediate structure between \
> parser and interpreting code where it is possible to push back the current element \
> back to have some other code handle it.
>
> See the mail thread http://marc.theaimsgroup.com/?t=109902729200001&r=1&w=2 for more information
>
>
>
>
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://nagoya.apache.org/jira/secure/Administrators.jspa
> -
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
>
[jira] Assigned: (AXISCPP-257) in WSDLs treated same as
Posted by "Dushshantha Chandradasa (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-257?page=all ]
Dushshantha Chandradasa reassigned AXISCPP-257:
-----------------------------------------------
Assign To: Dushshantha Chandradasa
> <xsd:all> in WSDLs treated same as <xsd:sequence>
> -------------------------------------------------
>
> Key: AXISCPP-257
> URL: http://issues.apache.org/jira/browse/AXISCPP-257
> Project: Axis-C++
> Type: New Feature
> Components: Basic Architecture, WSDL processing - RPC
> Versions: current (nightly), 1.3 Final
> Reporter: Samisa Abeysinghe
> Assignee: Dushshantha Chandradasa
> Attachments: WS021A.wsdl
>
> From mailing list:
> Samisa->
> Can we expect the SOAP message to have the elements in the same order defined by the
> WSDL? If yes (I think it is) we are OK. If not we have another bug :(
> Adrian Smith ->
> If the schema says <xs:sequence> then yes, the order is expected to be
> correct, but not if it says <xs:all>
> Carsten->
> I also looked at <xsd:choice>, which also has arbitrary ordering of a finite choices. \
> My impression was that the generated stubs was not able to handle that at all. \
> Typically there would be something like a switch for all the possiblities.
> What I have seen to deal with cases like this is an intermediate structure between \
> parser and interpreting code where it is possible to push back the current element \
> back to have some other code handle it.
> See the mail thread http://marc.theaimsgroup.com/?t=109902729200001&r=1&w=2 for more information
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (AXISCPP-257) in WSDLs treated same as
Posted by "John Hawkins (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-257?page=history ]
John Hawkins reassigned AXISCPP-257:
------------------------------------
Assign To: Adrian Dick
> <xsd:all> in WSDLs treated same as <xsd:sequence>
> -------------------------------------------------
>
> Key: AXISCPP-257
> URL: http://issues.apache.org/jira/browse/AXISCPP-257
> Project: Axis-C++
> Type: Bug
> Components: Basic Architecture, WSDL processing
> Versions: current (nightly), 1.3 Final
> Reporter: Samisa Abeysinghe
> Assignee: Adrian Dick
> Attachments: WS021A.wsdl
>
> From mailing list:
> Samisa->
> Can we expect the SOAP message to have the elements in the same order defined by the
> WSDL? If yes (I think it is) we are OK. If not we have another bug :(
> Adrian Smith ->
> If the schema says <xs:sequence> then yes, the order is expected to be
> correct, but not if it says <xs:all>
> Carsten->
> I also looked at <xsd:choice>, which also has arbitrary ordering of a finite choices. \
> My impression was that the generated stubs was not able to handle that at all. \
> Typically there would be something like a switch for all the possiblities.
> What I have seen to deal with cases like this is an intermediate structure between \
> parser and interpreting code where it is possible to push back the current element \
> back to have some other code handle it.
> See the mail thread http://marc.theaimsgroup.com/?t=109902729200001&r=1&w=2 for more information
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXISCPP-257) in WSDLs treated same as
Posted by "Adrian Smith (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXISCPP-257?page=history ]
Adrian Smith updated AXISCPP-257:
---------------------------------
Attachment: WS021A.wsdl
Sample WSDL as requested
> <xsd:all> in WSDLs treated same as <xsd:sequence>
> -------------------------------------------------
>
> Key: AXISCPP-257
> URL: http://nagoya.apache.org/jira/browse/AXISCPP-257
> Project: Axis-C++
> Type: Bug
> Components: Basic Architecture, WSDL processing
> Versions: current (nightly), 1.3 Final
> Reporter: Samisa Abeysinghe
> Attachments: WS021A.wsdl
>
> From mailing list:
> Samisa->
> Can we expect the SOAP message to have the elements in the same order defined by the
> WSDL? If yes (I think it is) we are OK. If not we have another bug :(
> Adrian Smith ->
> If the schema says <xs:sequence> then yes, the order is expected to be
> correct, but not if it says <xs:all>
> Carsten->
> I also looked at <xsd:choice>, which also has arbitrary ordering of a finite choices. \
> My impression was that the generated stubs was not able to handle that at all. \
> Typically there would be something like a switch for all the possiblities.
> What I have seen to deal with cases like this is an intermediate structure between \
> parser and interpreting code where it is possible to push back the current element \
> back to have some other code handle it.
> See the mail thread http://marc.theaimsgroup.com/?t=109902729200001&r=1&w=2 for more information
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (AXISCPP-257) in WSDLs treated same as
Posted by "Dushshantha Chandradasa (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-257?page=all ]
Dushshantha Chandradasa closed AXISCPP-257:
-------------------------------------------
Resolution: Fixed
all construct is now supported.
> <xsd:all> in WSDLs treated same as <xsd:sequence>
> -------------------------------------------------
>
> Key: AXISCPP-257
> URL: http://issues.apache.org/jira/browse/AXISCPP-257
> Project: Axis-C++
> Type: New Feature
> Components: Basic Architecture, WSDL processing - RPC
> Versions: current (nightly), 1.3 Final
> Reporter: Samisa Abeysinghe
> Assignee: Dushshantha Chandradasa
> Attachments: WS021A.wsdl
>
> From mailing list:
> Samisa->
> Can we expect the SOAP message to have the elements in the same order defined by the
> WSDL? If yes (I think it is) we are OK. If not we have another bug :(
> Adrian Smith ->
> If the schema says <xs:sequence> then yes, the order is expected to be
> correct, but not if it says <xs:all>
> Carsten->
> I also looked at <xsd:choice>, which also has arbitrary ordering of a finite choices. \
> My impression was that the generated stubs was not able to handle that at all. \
> Typically there would be something like a switch for all the possiblities.
> What I have seen to deal with cases like this is an intermediate structure between \
> parser and interpreting code where it is possible to push back the current element \
> back to have some other code handle it.
> See the mail thread http://marc.theaimsgroup.com/?t=109902729200001&r=1&w=2 for more information
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-257) in WSDLs treated same as
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-257?page=comments#action_65822 ]
Samisa Abeysinghe commented on AXISCPP-257:
-------------------------------------------
Have we tested with the wsdl file attached to this issue?
> <xsd:all> in WSDLs treated same as <xsd:sequence>
> -------------------------------------------------
>
> Key: AXISCPP-257
> URL: http://issues.apache.org/jira/browse/AXISCPP-257
> Project: Axis-C++
> Type: New Feature
> Components: Basic Architecture, WSDL processing - RPC
> Versions: current (nightly), 1.3 Final
> Reporter: Samisa Abeysinghe
> Assignee: Dushshantha Chandradasa
> Attachments: WS021A.wsdl
>
> From mailing list:
> Samisa->
> Can we expect the SOAP message to have the elements in the same order defined by the
> WSDL? If yes (I think it is) we are OK. If not we have another bug :(
> Adrian Smith ->
> If the schema says <xs:sequence> then yes, the order is expected to be
> correct, but not if it says <xs:all>
> Carsten->
> I also looked at <xsd:choice>, which also has arbitrary ordering of a finite choices. \
> My impression was that the generated stubs was not able to handle that at all. \
> Typically there would be something like a switch for all the possiblities.
> What I have seen to deal with cases like this is an intermediate structure between \
> parser and interpreting code where it is possible to push back the current element \
> back to have some other code handle it.
> See the mail thread http://marc.theaimsgroup.com/?t=109902729200001&r=1&w=2 for more information
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXISCPP-257) in WSDLs treated same as
Posted by "Adrian Dick (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-257?page=history ]
Adrian Dick updated AXISCPP-257:
--------------------------------
Assign To: (was: Adrian Dick)
type: New Feature (was: Bug)
This appears to be the request the support of an additional piece of SOAP/WSDL web services capability, therefore changing issue type to "New Feature"
> <xsd:all> in WSDLs treated same as <xsd:sequence>
> -------------------------------------------------
>
> Key: AXISCPP-257
> URL: http://issues.apache.org/jira/browse/AXISCPP-257
> Project: Axis-C++
> Type: New Feature
> Components: Basic Architecture, WSDL processing
> Versions: current (nightly), 1.3 Final
> Reporter: Samisa Abeysinghe
> Attachments: WS021A.wsdl
>
> From mailing list:
> Samisa->
> Can we expect the SOAP message to have the elements in the same order defined by the
> WSDL? If yes (I think it is) we are OK. If not we have another bug :(
> Adrian Smith ->
> If the schema says <xs:sequence> then yes, the order is expected to be
> correct, but not if it says <xs:all>
> Carsten->
> I also looked at <xsd:choice>, which also has arbitrary ordering of a finite choices. \
> My impression was that the generated stubs was not able to handle that at all. \
> Typically there would be something like a switch for all the possiblities.
> What I have seen to deal with cases like this is an intermediate structure between \
> parser and interpreting code where it is possible to push back the current element \
> back to have some other code handle it.
> See the mail thread http://marc.theaimsgroup.com/?t=109902729200001&r=1&w=2 for more information
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira