Re: [ogsa-hpcp-wg] Another Problem (maybe?) in the WSDL
Doesn't JSDL cause problems for your tooling as well? Element refs are a very common XMLSchema feature. JSDL uses quite a number of them. What about the HPCProfileApplication schema? I'm wondering whether changing the BES schema would actually help that much. I'm also worried that changing the demo copy of the schema for broken tooling would cause those changes to get propagated to the normative BES schema. My personal preference is that you change it locally rather than forcing us to endorse the change. Peter Mark Morgan wrote:
OK -- I thought as much. So, my tooling is bad -- can we change the WSDL anyway since the change shouldn't only be duplicate information for other peoples tooling (the goal is to be maximally interoperable right?). Ofcourse, I have to change the WSDL one way or the other, would just like to use the same WSDL everyone else is using.
-Mark
-----Original Message----- From: Peter G. Lane [mailto:lane@mcs.anl.gov] Sent: Friday, October 20, 2006 5:04 PM To: Mark Morgan Cc: ogsa-hpcp-wg@ggf.org Subject: Re: [ogsa-hpcp-wg] Another Problem (maybe?) in the WSDL
From the XMLSchema spec (http://www.w3.org/TR/xmlschema11-1/#cElement_Declarations):
"The (top-level) element declaration .resolved. to by the .actual value. of the ref [attribute]."
This means essentially that the global element declaration will be substituted for the element reference. In other words, the name must be "ActivityIdentifier" in the bes-factory namespace. If your tooling isn't doing this then it's non-compliant.
Peter
In trying to interop with Glenn's endpoint, I have found another potential problem with the BES-Factory's WSDL. However,
is at a level of WSDL that is slightly beyond my experience. In particular, the problem is with two message types; the GetActivityDocuments message type, and the TerminateActivitiesType message. Both problems are identical. In brief, here are three elements from the WSDL (the first of which is an example of a type declaration which works for me, and the latter two being
<xsd:complexType name="GetActivityStatusesType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" type="wsa:EndpointReferenceType" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="GetActivityDocumentsType"> <xsd:sequence> <xsd:element ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="TerminateActivitiesType"> <xsd:sequence> <xsd:element ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
The first one works for me, and the last two do not. The
Mark Morgan wrote: the problem the problem declarations). problem with
the second and third ones is that my tooling doesn't know what name to give the element for the EPRs inside of the message elements.. In otherwords, it generates messages which look like the following:
<GetActivityDocuments xmlns="http://schemas.ggf.org/bes/2006/08/bes-factory"> <item xmlns="" xmlns:ns3="http://www.w3.org/2005/08/addressing" xsi:type="ns3:EndpointReferenceType">
<ns3:Address>https://wincluster1.cs.virginia.edu/HPCP/HPCPServ ice.asmx</ns3:
Address> <ns3:ReferenceParameters> <jobID xmlns="http://schemas.ggf.org/hpcp/2006/07/hpcp-app">113</jobID> </ns3:ReferenceParameters> </item> </GetActivityDocuments>
<TerminateActivities xmlns="http://schemas.ggf.org/bes/2006/08/bes-factory"> <item xmlns="" xmlns:ns3="http://www.w3.org/2005/08/addressing" xsi:type="ns3:EndpointReferenceType">
<ns3:Address>https://wincluster1.cs.virginia.edu/HPCP/HPCPServ ice.asmx</ns3:
Address> <ns3:ReferenceParameters> <jobID xmlns="http://schemas.ggf.org/hpcp/2006/07/hpcp-app">113</jobID> </ns3:ReferenceParameters> </item> </TerminateActivities>
Notice the child element called "item" in each message.
The simple (and obvious to me) fix was to change the GetActivityDocuemntsType and TerminateActivitiesType type definitions to specify the name of the inner element, i.e. to change them to:
<xsd:complexType name="GetActivityDocumentsType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="TerminateActivitiesType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
I know that these are legitimate fixs, the questions are, A) are these in fact real errors that my tooling is finding and thus the WSDL is in error, and B) can we make these changes permanent in the BES-Factory WSDL to fix these problem?
-Mark
-- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.cs.virginia.edu mmm2a@virginia.edu (434) 982-2047
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
Strangely enough, the JSDL doesn't have problems. And, as a matter of fact, the same pattern shows up in the result types and those are OK as well. It only occurs for the client sending outgoing requests. I'm not sure what the difference would be though since the same tooling generates both the client stubs and the server side skeleton. Interestingly enough, I would expect your own clients to exhibit this behavior as well unless you have replaced or manually edited the Axis WSDL2Java tooling (forgive me if I'm making a stupid assumption, but I am under the impression that Globus is based off of the same version of Axis that I use). At anyrate, if this problem does turn out to be the tooling in Axis, not only would I be OK with the changes making it back into the BES group, but I would sincerely hope that the whole point of this excersize is to provide useful feedback to that group about issues like this. After all, the goal of OGSA, OGF, and the BES and HPC working groups is to promote interoperability and to maximize everyone's chances at equally interoperating with each other. To my way of thinking, this explicitly means that if two pieces of WSDL describe the same exact wire format, but one works with a larger set of tooling, then despite the correctness of the other, we as an open standards organization have an obligation to use the format that works for everyone, even the broken tooling sets. -Mark On Fri, Oct 20, 2006 at 04:41:55PM -0600, Peter G. Lane wrote:
Doesn't JSDL cause problems for your tooling as well? Element refs are a very common XMLSchema feature. JSDL uses quite a number of them. What about the HPCProfileApplication schema? I'm wondering whether changing the BES schema would actually help that much. I'm also worried that changing the demo copy of the schema for broken tooling would cause those changes to get propagated to the normative BES schema. My personal preference is that you change it locally rather than forcing us to endorse the change.
Peter
Mark Morgan wrote:
OK -- I thought as much. So, my tooling is bad -- can we change the WSDL anyway since the change shouldn't only be duplicate information for other peoples tooling (the goal is to be maximally interoperable right?). Ofcourse, I have to change the WSDL one way or the other, would just like to use the same WSDL everyone else is using.
-Mark
-----Original Message----- From: Peter G. Lane [mailto:lane@mcs.anl.gov] Sent: Friday, October 20, 2006 5:04 PM To: Mark Morgan Cc: ogsa-hpcp-wg@ggf.org Subject: Re: [ogsa-hpcp-wg] Another Problem (maybe?) in the WSDL
From the XMLSchema spec (http://www.w3.org/TR/xmlschema11-1/#cElement_Declarations):
"The (top-level) element declaration .resolved. to by the .actual value. of the ref [attribute]."
This means essentially that the global element declaration will be substituted for the element reference. In other words, the name must be "ActivityIdentifier" in the bes-factory namespace. If your tooling isn't doing this then it's non-compliant.
Peter
In trying to interop with Glenn's endpoint, I have found another potential problem with the BES-Factory's WSDL. However,
is at a level of WSDL that is slightly beyond my experience. In particular, the problem is with two message types; the GetActivityDocuments message type, and the TerminateActivitiesType message. Both problems are identical. In brief, here are three elements from the WSDL (the first of which is an example of a type declaration which works for me, and the latter two being
<xsd:complexType name="GetActivityStatusesType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" type="wsa:EndpointReferenceType" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="GetActivityDocumentsType"> <xsd:sequence> <xsd:element ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="TerminateActivitiesType"> <xsd:sequence> <xsd:element ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
The first one works for me, and the last two do not. The
Mark Morgan wrote: the problem the problem declarations). problem with
the second and third ones is that my tooling doesn't know what name to give the element for the EPRs inside of the message elements.. In otherwords, it generates messages which look like the following:
<GetActivityDocuments xmlns="http://schemas.ggf.org/bes/2006/08/bes-factory"> <item xmlns="" xmlns:ns3="http://www.w3.org/2005/08/addressing" xsi:type="ns3:EndpointReferenceType">
<ns3:Address>https://wincluster1.cs.virginia.edu/HPCP/HPCPServ ice.asmx</ns3:
Address> <ns3:ReferenceParameters> <jobID xmlns="http://schemas.ggf.org/hpcp/2006/07/hpcp-app">113</jobID> </ns3:ReferenceParameters> </item> </GetActivityDocuments>
<TerminateActivities xmlns="http://schemas.ggf.org/bes/2006/08/bes-factory"> <item xmlns="" xmlns:ns3="http://www.w3.org/2005/08/addressing" xsi:type="ns3:EndpointReferenceType">
<ns3:Address>https://wincluster1.cs.virginia.edu/HPCP/HPCPServ ice.asmx</ns3:
Address> <ns3:ReferenceParameters> <jobID xmlns="http://schemas.ggf.org/hpcp/2006/07/hpcp-app">113</jobID> </ns3:ReferenceParameters> </item> </TerminateActivities>
Notice the child element called "item" in each message.
The simple (and obvious to me) fix was to change the GetActivityDocuemntsType and TerminateActivitiesType type definitions to specify the name of the inner element, i.e. to change them to:
<xsd:complexType name="GetActivityDocumentsType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="TerminateActivitiesType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
I know that these are legitimate fixs, the questions are, A) are these in fact real errors that my tooling is finding and thus the WSDL is in error, and B) can we make these changes permanent in the BES-Factory WSDL to fix these problem?
-Mark
-- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.cs.virginia.edu mmm2a@virginia.edu (434) 982-2047
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
Mark M. Morgan wrote:
Strangely enough, the JSDL doesn't have problems. And, as a matter of fact, the same pattern shows up in the result types and those are OK as well. It only occurs for the client sending outgoing requests. I'm not sure what the difference would be though since the same tooling generates both the client stubs and the server side skeleton. Interestingly enough, I would expect your own clients to exhibit this behavior as well unless you have replaced or manually edited the Axis WSDL2Java tooling (forgive me if I'm making a stupid assumption, but I am under the impression that Globus is based off of the same version of Axis that I use).
We're using Axis version 1.5 and it seems to work fine: <GetActivityDocuments xmlns="http://schemas.globus.org/gram/2006/05/job/factory"> <ActivityIdentifier xsi:type="wsa:EndpointReferenceType"> <wsa:Address>https://192.168.0.101:8443/wsrf/services/ManagedExecutableJobService</wsa:Address> <wsa:ReferenceProperties> <ns1:ResourceID xmlns:ns1="http://www.globus.org/namespaces/2004/10/gram/job">2e3ee6f0-60ab-11db-bc36-acbb2a153f40</ns1:ResourceID> </wsa:ReferenceProperties> <wsa:ReferenceParameters/> </ActivityIdentifier> </GetActivityDocuments>
At anyrate, if this problem does turn out to be the tooling in Axis, not only would I be OK with the changes making it back into the BES group, but I would sincerely hope that the whole point of this excersize is to provide useful feedback to that group about issues like this. After all, the goal of OGSA, OGF, and the BES and HPC working groups is to promote interoperability and to maximize everyone's chances at equally interoperating with each other. To my way of thinking, this explicitly means that if two pieces of WSDL describe the same exact wire format, but one works with a larger set of tooling, then despite the correctness of the other, we as an open standards organization have an obligation to use the format that works for everyone, even the broken tooling sets.
While I understand what you're saying, I also think this can be a slippery slope. Admittedly the change you're asking for is quite minor, but my stubbornness kicks in when I think of it like this: how do we attain interoperability without making everybody implement N different variations of the specs we use? If we let people be non-conformant and even bend over backwards when they are non-conformant, we're putting the burden on everybody to accomodate all non-conformant variations that may pop up. That's no way to operate in my mind. You should define the dimensions of your widget and then mass produce it. Slight variations may occur within tolerances, but element refs to me isn't within tolerances. They're pretty fundamental IMHO. Anyway, I'm off my soap (no pun intended) box. Since the change is rather benign, I'm not going to get in a tiff if others agree this is worth doing. But if you want to switch to a working Axis version, you're welcome to use the Globus Toolkit! ;-) Peter
-Mark
On Fri, Oct 20, 2006 at 04:41:55PM -0600, Peter G. Lane wrote:
Doesn't JSDL cause problems for your tooling as well? Element refs are a very common XMLSchema feature. JSDL uses quite a number of them. What about the HPCProfileApplication schema? I'm wondering whether changing the BES schema would actually help that much. I'm also worried that changing the demo copy of the schema for broken tooling would cause those changes to get propagated to the normative BES schema. My personal preference is that you change it locally rather than forcing us to endorse the change.
Peter
Mark Morgan wrote:
OK -- I thought as much. So, my tooling is bad -- can we change the WSDL anyway since the change shouldn't only be duplicate information for other peoples tooling (the goal is to be maximally interoperable right?). Ofcourse, I have to change the WSDL one way or the other, would just like to use the same WSDL everyone else is using.
-Mark
-----Original Message----- From: Peter G. Lane [mailto:lane@mcs.anl.gov] Sent: Friday, October 20, 2006 5:04 PM To: Mark Morgan Cc: ogsa-hpcp-wg@ggf.org Subject: Re: [ogsa-hpcp-wg] Another Problem (maybe?) in the WSDL
From the XMLSchema spec (http://www.w3.org/TR/xmlschema11-1/#cElement_Declarations):
"The (top-level) element declaration .resolved. to by the .actual value. of the ref [attribute]."
This means essentially that the global element declaration will be substituted for the element reference. In other words, the name must be "ActivityIdentifier" in the bes-factory namespace. If your tooling isn't doing this then it's non-compliant.
Peter
In trying to interop with Glenn's endpoint, I have found another potential problem with the BES-Factory's WSDL. However,
is at a level of WSDL that is slightly beyond my experience. In particular, the problem is with two message types; the GetActivityDocuments message type, and the TerminateActivitiesType message. Both problems are identical. In brief, here are three elements from the WSDL (the first of which is an example of a type declaration which works for me, and the latter two being
<xsd:complexType name="GetActivityStatusesType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" type="wsa:EndpointReferenceType" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="GetActivityDocumentsType"> <xsd:sequence> <xsd:element ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="TerminateActivitiesType"> <xsd:sequence> <xsd:element ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
The first one works for me, and the last two do not. The
Mark Morgan wrote: the problem the problem declarations). problem with
the second and third ones is that my tooling doesn't know what name to give the element for the EPRs inside of the message elements.. In otherwords, it generates messages which look like the following:
<GetActivityDocuments xmlns="http://schemas.ggf.org/bes/2006/08/bes-factory"> <item xmlns="" xmlns:ns3="http://www.w3.org/2005/08/addressing" xsi:type="ns3:EndpointReferenceType">
<ns3:Address>https://wincluster1.cs.virginia.edu/HPCP/HPCPServ ice.asmx</ns3:
Address> <ns3:ReferenceParameters> <jobID xmlns="http://schemas.ggf.org/hpcp/2006/07/hpcp-app">113</jobID> </ns3:ReferenceParameters> </item> </GetActivityDocuments>
<TerminateActivities xmlns="http://schemas.ggf.org/bes/2006/08/bes-factory"> <item xmlns="" xmlns:ns3="http://www.w3.org/2005/08/addressing" xsi:type="ns3:EndpointReferenceType">
<ns3:Address>https://wincluster1.cs.virginia.edu/HPCP/HPCPServ ice.asmx</ns3:
Address> <ns3:ReferenceParameters> <jobID xmlns="http://schemas.ggf.org/hpcp/2006/07/hpcp-app">113</jobID> </ns3:ReferenceParameters> </item> </TerminateActivities>
Notice the child element called "item" in each message.
The simple (and obvious to me) fix was to change the GetActivityDocuemntsType and TerminateActivitiesType type definitions to specify the name of the inner element, i.e. to change them to:
<xsd:complexType name="GetActivityDocumentsType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="TerminateActivitiesType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
I know that these are legitimate fixs, the questions are, A) are these in fact real errors that my tooling is finding and thus the WSDL is in error, and B) can we make these changes permanent in the BES-Factory WSDL to fix these problem?
-Mark
-- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.cs.virginia.edu mmm2a@virginia.edu (434) 982-2047
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
We're using Axis version 1.5 and it seems to work fine:
Ah, my bad -- we're still using 1.4
While I understand what you're saying, I also think this can be a slippery slope. Admittedly the change you're asking for is quite minor, but my stubbornness kicks in when I think of it like this: how do we attain interoperability without making everybody implement N different variations of the specs we use? If we let people be non-conformant and even bend over backwards when they are non-conformant, we're putting the burden on everybody to accomodate all non-conformant variations that may pop up. That's no way to operate in my mind. You should define the dimensions of your widget and then mass produce it. Slight variations may occur within tolerances, but element refs to me isn't within tolerances. They're pretty fundamental IMHO.
Well, my experience has been that WSDL, like C++ of old, has gotten too complicated and as such, NO ONE correctly implements it 100%. This happens to be a problem that mine has -- next it could be yours.
Anyway, I'm off my soap (no pun intended) box. Since the change is rather benign, I'm not going to get in a tiff if others agree this is worth doing. But if you want to switch to a working Axis version, you're welcome to use the Globus Toolkit! ;-)
That's OK -- like I said, I don't believe yours is 100% correct either, so I'll stick with the one I know and can fix. And don't worry about the WSDL, I just thought we might want to find a common subset of WSDL that everyone understands, but seeing as how this isn't the trivial issue I thought it was, I'll just post an alternate but equivalent form of the WSDL that people using Axis 1.4 can use. -Mark
Peter
-Mark
On Fri, Oct 20, 2006 at 04:41:55PM -0600, Peter G. Lane wrote:
Doesn't JSDL cause problems for your tooling as well? Element refs are a very common XMLSchema feature. JSDL uses quite a number of them. What about the HPCProfileApplication schema? I'm wondering whether changing the BES schema would actually help that much. I'm also worried that changing the demo copy of the schema for broken tooling would cause those changes to get propagated to the normative BES schema. My personal preference is that you change it locally rather than forcing us to endorse the change.
Peter
Mark Morgan wrote:
OK -- I thought as much. So, my tooling is bad -- can we change the WSDL anyway since the change shouldn't only be duplicate information for other peoples tooling (the goal is to be maximally interoperable right?). Ofcourse, I have to change the WSDL one way or the other, would just like to use the same WSDL everyone else is using.
-Mark
-----Original Message----- From: Peter G. Lane [mailto:lane@mcs.anl.gov] Sent: Friday, October 20, 2006 5:04 PM To: Mark Morgan Cc: ogsa-hpcp-wg@ggf.org Subject: Re: [ogsa-hpcp-wg] Another Problem (maybe?) in the WSDL
From the XMLSchema spec (http://www.w3.org/TR/xmlschema11-1/#cElement_Declarations):
"The (top-level) element declaration .resolved. to by the .actual value. of the ref [attribute]."
This means essentially that the global element declaration will be substituted for the element reference. In other words, the name must be "ActivityIdentifier" in the bes-factory namespace. If your tooling isn't doing this then it's non-compliant.
Peter
In trying to interop with Glenn's endpoint, I have found another potential problem with the BES-Factory's WSDL. However,
is at a level of WSDL that is slightly beyond my experience. In particular, the problem is with two message types; the GetActivityDocuments message type, and the TerminateActivitiesType message. Both problems are identical. In brief, here are three elements from the WSDL (the first of which is an example of a type declaration which works for me, and the latter two being
<xsd:complexType name="GetActivityStatusesType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" type="wsa:EndpointReferenceType" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="GetActivityDocumentsType"> <xsd:sequence> <xsd:element ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="TerminateActivitiesType"> <xsd:sequence> <xsd:element ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
The first one works for me, and the last two do not. The
Mark Morgan wrote: the problem the problem declarations). problem with
the second and third ones is that my tooling doesn't know what name to give the element for the EPRs inside of the message elements.. In otherwords, it generates messages which look like the following:
<GetActivityDocuments xmlns="http://schemas.ggf.org/bes/2006/08/bes-factory"> <item xmlns="" xmlns:ns3="http://www.w3.org/2005/08/addressing" xsi:type="ns3:EndpointReferenceType">
<ns3:Address>https://wincluster1.cs.virginia.edu/HPCP/HPCPServ ice.asmx</ns3:
Address> <ns3:ReferenceParameters> <jobID xmlns="http://schemas.ggf.org/hpcp/2006/07/hpcp-app">113</jobID> </ns3:ReferenceParameters> </item> </GetActivityDocuments>
<TerminateActivities xmlns="http://schemas.ggf.org/bes/2006/08/bes-factory"> <item xmlns="" xmlns:ns3="http://www.w3.org/2005/08/addressing" xsi:type="ns3:EndpointReferenceType">
<ns3:Address>https://wincluster1.cs.virginia.edu/HPCP/HPCPServ ice.asmx</ns3:
Address> <ns3:ReferenceParameters> <jobID xmlns="http://schemas.ggf.org/hpcp/2006/07/hpcp-app">113</jobID> </ns3:ReferenceParameters> </item> </TerminateActivities>
Notice the child element called "item" in each message.
The simple (and obvious to me) fix was to change the GetActivityDocuemntsType and TerminateActivitiesType type definitions to specify the name of the inner element, i.e. to change them to:
<xsd:complexType name="GetActivityDocumentsType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="TerminateActivitiesType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
I know that these are legitimate fixs, the questions are, A) are these in fact real errors that my tooling is finding and thus the WSDL is in error, and B) can we make these changes permanent in the BES-Factory WSDL to fix these problem?
-Mark
-- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.cs.virginia.edu mmm2a@virginia.edu (434) 982-2047
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
participants (2)
-
Mark M. Morgan -
Peter G. Lane