wsdl/xsd modifications for BES v26
Hello, As part of the HPC Profile interop work, I have been trying to process the BES v26 WSDL through my tooling (Microsoft's wsdl.exe). I have found a number of problems with the BES-Factory wsdl and xsd that appears in the appendix of the BES document. Some of these issues are simple typos and some require re-formulations of the wsdl/xsd in order to work with the tooling. I have attached modified versions of both the wsdl and xsd for bes-factory and, below, I have provided a summary of the changes. I contend that these changes (apart from fixing typos) don't actually change the defined interface/data types - they are merely an alternate way of expressing the same ideas using wsdl/xsd that (at least my) tooling can handle. I am interested in: a) comments on this reformulation b) whether anyone else, who is using different tools, has had similar (or different) issues with the wsdl/xsd in the BES v26 appendix c) whether anyone using different tools encounters issues processing the attached wsdl/xsd d) whether people participating in the HPCP interop work are willing to use the attached wsdl/xsd Glenn Summary of changes: 1. bes-factory wsdl (appendix E) and bes-factory xsd (appendix B) both have <xsd:schema> elements with the same target namespace - moved schema types from bes-factory.wsdl to bes-factory.xsd - changed <schema> element in bes-factory.wsdl to only import bes- factory.xsd (other imports seemed to create problems because the same schemas were also imported in the bes-factory.xsd file) - changed target namespace of <xsd:schema> element in bes-factory.wsdl to http://schemas.ggf.org/bes/2006/08/bes-factory/WSDL (added the /WSDL) - This doesn't effect anything since no types are defined in the bes- factory.wsdl's <xsd:schema>, but was necessary to prevent the namespace collision 2. the operation "ResponseType" elements are multiply defined - both the wsdl and xsd define <xsd:element>s for, for example, CreateActivityResponse (the definitions differ only in the name of an outer element wrapper) - kept the definition with the outer element wrapper around the type (i.e. <Response> as the outer element) - moved this definition to bes-factory.xsd and simply reference it from bes-factory.wsdl 3. typos in the types of the response elements for several operations - GetActivityStatusesResponse, TerminateActivitiesResponse, GetActivityDocumentsResponse should be of types GetActivityStatusesResponseType, TerminateActivitiesResponseType, GetActivityDocumentsResponseType respectively 4. added minOccurs and maxOccurs to the GetAttributesDocument related classes - spec seems undecided here
On Sep 28, 2006, at 10:22 AM, Glenn Wasson wrote:
Hello,
As part of the HPC Profile interop work, I have been trying to process the BES v26 WSDL through my tooling (Microsoft's wsdl.exe). I have found a number of problems with the BES-Factory wsdl and xsd that appears in the appendix of the BES document. Some of these issues are simple typos and some require re-formulations of the wsdl/xsd in order to work with the tooling. I have attached modified versions of both the wsdl and xsd for bes-factory and, below, I have provided a summary of the changes. I contend that these changes (apart from fixing typos) don't actually change the defined interface/data types - they are merely an alternate way of expressing the same ideas using wsdl/xsd that (at least my) tooling can handle.
I am interested in: a) comments on this reformulation b) whether anyone else, who is using different tools, has had similar (or different) issues with the wsdl/xsd in the BES v26 appendix c) whether anyone using different tools encounters issues processing the attached wsdl/xsd d) whether people participating in the HPCP interop work are willing to use the attached wsdl/xsd
Glenn
Summary of changes: 1. bes-factory wsdl (appendix E) and bes-factory xsd (appendix B) both have
<xsd:schema> elements with the same target namespace - moved schema types from bes-factory.wsdl to bes-factory.xsd
I disagree with this change. Unless we think someone will need to import the message types, they aren't relevant anywhere except within the WSDL and should remain there.
- changed <schema> element in bes-factory.wsdl to only import bes- factory.xsd (other imports seemed to create problems because the same
schemas were also imported in the bes-factory.xsd file) - changed target namespace of <xsd:schema> element in bes- factory.wsdl to http://schemas.ggf.org/bes/2006/08/bes-factory/WSDL (added the /WSDL) - This doesn't effect anything since no types are defined in the bes- factory.wsdl's <xsd:schema>, but was necessary to prevent the namespace collision
This should be an xsd:include, then, not an xsd:import: <xsd:include schemaLocation="bes-factory.xsd"/> No need to hack a namespace into the WSDL's schema section...
2. the operation "ResponseType" elements are multiply defined - both the wsdl and xsd define <xsd:element>s for, for example, CreateActivityResponse (the definitions differ only in the name of an
outer element wrapper) - kept the definition with the outer element wrapper around the type (i.e. <Response> as the outer element)
The types weren't the same at all. One set was the single-activity type which is then referenced in the multi-activity type that is actually used in the BES factory operation messages.
- moved this definition to bes-factory.xsd and simply reference it from
bes-factory.wsdl 3. typos in the types of the response elements for several operations - GetActivityStatusesResponse, TerminateActivitiesResponse, GetActivityDocumentsResponse should be of types GetActivityStatusesResponseType, TerminateActivitiesResponseType, GetActivityDocumentsResponseType respectively 4. added minOccurs and maxOccurs to the GetAttributesDocument related classes - spec seems undecided here
I fixed the things I commented on above and am attaching new versions of these two files. I've also validated them with the GT tooling. Peter
<bes-factory.xsd> <bes-factory.wsdl> -- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
-----Original Message----- From: Peter Lane [mailto:lane@mcs.anl.gov] Sent: Thursday, September 28, 2006 11:05 PM To: Glenn Wasson Cc: ogsa-hpcp-wg@ggf.org; ogsa-bes-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] wsdl/xsd modifications for BES v26
Summary of changes: 1. bes-factory wsdl (appendix E) and bes-factory xsd (appendix B) both have
<xsd:schema> elements with the same target namespace - moved schema types from bes-factory.wsdl to bes-factory.xsd
I disagree with this change. Unless we think someone will need to import the message types, they aren't relevant anywhere except within the WSDL and should remain there.
- changed <schema> element in bes-factory.wsdl to only import bes- factory.xsd (other imports seemed to create problems because the same
schemas were also imported in the bes-factory.xsd file) - changed target namespace of <xsd:schema> element in bes- factory.wsdl to http://schemas.ggf.org/bes/2006/08/bes-factory/WSDL (added the /WSDL) - This doesn't effect anything since no types are defined in the bes- factory.wsdl's <xsd:schema>, but was necessary to prevent the namespace collision
This should be an xsd:include, then, not an xsd:import:
<xsd:include schemaLocation="bes-factory.xsd"/>
No need to hack a namespace into the WSDL's schema section...
I've never been able to get this to work in my tooling, but that's ok. We can use your version.
2. the operation "ResponseType" elements are multiply defined - both the wsdl and xsd define <xsd:element>s for, for example, CreateActivityResponse (the definitions differ only in the name of an
outer element wrapper) - kept the definition with the outer element wrapper around the type (i.e. <Response> as the outer element)
The types weren't the same at all. One set was the single-activity type which is then referenced in the multi-activity type that is actually used in the BES factory operation messages.
Ah, yes, typo on my part. It is not the "ResponseType"s which were multiply defined, it is the "Response"s. So, CreateActivityResponseType was defined once, but CreateActivityResponse was defined twice. While I understand what you are saying, my tooling cannot handle the fact that (in the old wsdl/xsd) both the xsd and the wsdl define an <element> with the same qname. Even if other tooling can do this, I don't think it is a good idea. I also noticed that your version changes "GetAttributesDocument" to "GetFactoryAttributesDocument". Is this a post-v26 change to the WSDL? I'm fine with this operation name, it just wasn't in v26. Glenn
On Sep 29, 2006, at 4:02 AM, Glenn Wasson wrote:
-----Original Message----- From: Peter Lane [mailto:lane@mcs.anl.gov] Sent: Thursday, September 28, 2006 11:05 PM To: Glenn Wasson Cc: ogsa-hpcp-wg@ggf.org; ogsa-bes-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] wsdl/xsd modifications for BES v26
Summary of changes: 1. bes-factory wsdl (appendix E) and bes-factory xsd (appendix B) both have
<xsd:schema> elements with the same target namespace - moved schema types from bes-factory.wsdl to bes-factory.xsd
I disagree with this change. Unless we think someone will need to import the message types, they aren't relevant anywhere except within the WSDL and should remain there.
- changed <schema> element in bes-factory.wsdl to only import bes- factory.xsd (other imports seemed to create problems because the same
schemas were also imported in the bes-factory.xsd file) - changed target namespace of <xsd:schema> element in bes- factory.wsdl to http://schemas.ggf.org/bes/2006/08/bes-factory/WSDL (added the /WSDL) - This doesn't effect anything since no types are defined in the bes- factory.wsdl's <xsd:schema>, but was necessary to prevent the namespace collision
This should be an xsd:include, then, not an xsd:import:
<xsd:include schemaLocation="bes-factory.xsd"/>
No need to hack a namespace into the WSDL's schema section...
I've never been able to get this to work in my tooling, but that's ok. We can use your version.
2. the operation "ResponseType" elements are multiply defined - both the wsdl and xsd define <xsd:element>s for, for example, CreateActivityResponse (the definitions differ only in the name of an
outer element wrapper) - kept the definition with the outer element wrapper around the type (i.e. <Response> as the outer element)
The types weren't the same at all. One set was the single-activity type which is then referenced in the multi-activity type that is actually used in the BES factory operation messages.
Ah, yes, typo on my part. It is not the "ResponseType"s which were multiply defined, it is the "Response"s. So, CreateActivityResponseType was defined once, but CreateActivityResponse was defined twice. While I understand what you are saying, my tooling cannot handle the fact that (in the old wsdl/xsd) both the xsd and the wsdl define an <element> with the same qname. Even if other tooling can do this, I don't think it is a good idea.
There shouldn't be two elements in the same namespace with the same name. If there is one still, please point it out as this is an error.
I also noticed that your version changes "GetAttributesDocument" to "GetFactoryAttributesDocument". Is this a post-v26 change to the WSDL? I'm fine with this operation name, it just wasn't in v26.
I hope I got the name right. At OGF we decided that GetAttributesDocument for the factory and activity should be named differently to differentiate the two. Peter
Glenn
Hi, At this AM's SC06 interop demo conf call, we decided to change the response messages that use the s12:Fault type to xsd:anyType as a interim solution so we can proceed with the interop testing. Glenn had sent a separate email out regarding this issue earlier in the week. We also need to discuss a longer term solution within the context of the BES working group. I attached the updated bes-factory.xsd so Peter's WSDL + this XSD (derived from Peter's) are the latest versions for the demo at this time. Thanks -----Original Message----- From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Peter Lane Sent: Thursday, September 28, 2006 8:05 PM To: Glenn Wasson Cc: ogsa-hpcp-wg@ggf.org; ogsa-bes-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] wsdl/xsd modifications for BES v26 On Sep 28, 2006, at 10:22 AM, Glenn Wasson wrote:
Hello,
As part of the HPC Profile interop work, I have been trying to process the BES v26 WSDL through my tooling (Microsoft's wsdl.exe). I have found a number of problems with the BES-Factory wsdl and xsd that appears in the appendix of the BES document. Some of these issues are simple typos and some require re-formulations of the wsdl/xsd in order to work with the tooling. I have attached modified versions of both the wsdl and xsd for bes-factory and, below, I have provided a summary of the changes. I contend that these changes (apart from fixing typos) don't actually change the defined interface/data types - they are merely an alternate way of expressing the same ideas using wsdl/xsd that (at least my) tooling can handle.
I am interested in: a) comments on this reformulation b) whether anyone else, who is using different tools, has had similar (or different) issues with the wsdl/xsd in the BES v26 appendix c) whether anyone using different tools encounters issues processing the attached wsdl/xsd d) whether people participating in the HPCP interop work are willing to use the attached wsdl/xsd
Glenn
Summary of changes: 1. bes-factory wsdl (appendix E) and bes-factory xsd (appendix B) both have
<xsd:schema> elements with the same target namespace - moved schema types from bes-factory.wsdl to bes-factory.xsd
I disagree with this change. Unless we think someone will need to import the message types, they aren't relevant anywhere except within the WSDL and should remain there.
- changed <schema> element in bes-factory.wsdl to only import bes- factory.xsd (other imports seemed to create problems because the same
schemas were also imported in the bes-factory.xsd file) - changed target namespace of <xsd:schema> element in bes- factory.wsdl to http://schemas.ggf.org/bes/2006/08/bes-factory/WSDL (added the /WSDL) - This doesn't effect anything since no types are defined in the bes- factory.wsdl's <xsd:schema>, but was necessary to prevent the namespace collision
This should be an xsd:include, then, not an xsd:import: <xsd:include schemaLocation="bes-factory.xsd"/> No need to hack a namespace into the WSDL's schema section...
2. the operation "ResponseType" elements are multiply defined - both the wsdl and xsd define <xsd:element>s for, for example, CreateActivityResponse (the definitions differ only in the name of an
outer element wrapper) - kept the definition with the outer element wrapper around the type (i.e. <Response> as the outer element)
The types weren't the same at all. One set was the single-activity type which is then referenced in the multi-activity type that is actually used in the BES factory operation messages.
- moved this definition to bes-factory.xsd and simply reference it from
bes-factory.wsdl 3. typos in the types of the response elements for several operations - GetActivityStatusesResponse, TerminateActivitiesResponse, GetActivityDocumentsResponse should be of types GetActivityStatusesResponseType, TerminateActivitiesResponseType, GetActivityDocumentsResponseType respectively 4. added minOccurs and maxOccurs to the GetAttributesDocument related classes - spec seems undecided here
I fixed the things I commented on above and am attaching new versions of these two files. I've also validated them with the GT tooling. Peter
<bes-factory.xsd> <bes-factory.wsdl> -- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
Hey Rich, The schema still imports the s12 envelope schema ... should that be removed? The WSDL still references s12:Fault in CreateActivityResponseType. Is this intentional? -- Chris On 29/9/06 12:59, "Richard Ciapala" <richci@microsoft.com> wrote:
Hi,
At this AM's SC06 interop demo conf call, we decided to change the response messages that use the s12:Fault type to xsd:anyType as a interim solution so we can proceed with the interop testing. Glenn had sent a separate email out regarding this issue earlier in the week. We also need to discuss a longer term solution within the context of the BES working group.
I attached the updated bes-factory.xsd so Peter's WSDL + this XSD (derived from Peter's) are the latest versions for the demo at this time.
Thanks
-----Original Message----- From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Peter Lane Sent: Thursday, September 28, 2006 8:05 PM To: Glenn Wasson Cc: ogsa-hpcp-wg@ggf.org; ogsa-bes-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] wsdl/xsd modifications for BES v26
On Sep 28, 2006, at 10:22 AM, Glenn Wasson wrote:
Hello,
As part of the HPC Profile interop work, I have been trying to process the BES v26 WSDL through my tooling (Microsoft's wsdl.exe). I have found a number of problems with the BES-Factory wsdl and xsd that appears in the appendix of the BES document. Some of these issues are simple typos and some require re-formulations of the wsdl/xsd in order to work with the tooling. I have attached modified versions of both the wsdl and xsd for bes-factory and, below, I have provided a summary of the changes. I contend that these changes (apart from fixing typos) don't actually change the defined interface/data types - they are merely an alternate way of expressing the same ideas using wsdl/xsd that (at least my) tooling can handle.
I am interested in: a) comments on this reformulation b) whether anyone else, who is using different tools, has had similar (or different) issues with the wsdl/xsd in the BES v26 appendix c) whether anyone using different tools encounters issues processing the attached wsdl/xsd d) whether people participating in the HPCP interop work are willing to use the attached wsdl/xsd
Glenn
Summary of changes: 1. bes-factory wsdl (appendix E) and bes-factory xsd (appendix B) both have
<xsd:schema> elements with the same target namespace - moved schema types from bes-factory.wsdl to bes-factory.xsd
I disagree with this change. Unless we think someone will need to import the message types, they aren't relevant anywhere except within the WSDL and should remain there.
- changed <schema> element in bes-factory.wsdl to only import bes- factory.xsd (other imports seemed to create problems because the same
schemas were also imported in the bes-factory.xsd file) - changed target namespace of <xsd:schema> element in bes- factory.wsdl to http://schemas.ggf.org/bes/2006/08/bes-factory/WSDL (added the /WSDL) - This doesn't effect anything since no types are defined in the bes- factory.wsdl's <xsd:schema>, but was necessary to prevent the namespace collision
This should be an xsd:include, then, not an xsd:import:
<xsd:include schemaLocation="bes-factory.xsd"/>
No need to hack a namespace into the WSDL's schema section...
2. the operation "ResponseType" elements are multiply defined - both the wsdl and xsd define <xsd:element>s for, for example, CreateActivityResponse (the definitions differ only in the name of an
outer element wrapper) - kept the definition with the outer element wrapper around the type (i.e. <Response> as the outer element)
The types weren't the same at all. One set was the single-activity type which is then referenced in the multi-activity type that is actually used in the BES factory operation messages.
- moved this definition to bes-factory.xsd and simply reference it from
bes-factory.wsdl 3. typos in the types of the response elements for several operations - GetActivityStatusesResponse, TerminateActivitiesResponse, GetActivityDocumentsResponse should be of types GetActivityStatusesResponseType, TerminateActivitiesResponseType, GetActivityDocumentsResponseType respectively 4. added minOccurs and maxOccurs to the GetAttributesDocument related classes - spec seems undecided here
I fixed the things I commented on above and am attaching new versions of these two files. I've also validated them with the GT tooling.
Peter
<bes-factory.xsd> <bes-factory.wsdl> -- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
No it was a mistake. Thanks for catching this Chris. Here are the latest versions of the XSD and WSDL with the temporary fault adjustment in both. Thanks -----Original Message----- From: Christopher Smith [mailto:csmith@platform.com] Sent: Friday, September 29, 2006 1:14 PM To: Richard Ciapala; Peter Lane; Glenn Wasson Cc: ogsa-hpcp-wg@ggf.org; ogsa-bes-wg@ogf.org Subject: Re: [OGSA-BES-WG] [ogsa-hpcp-wg] wsdl/xsd modifications for BES v26 Hey Rich, The schema still imports the s12 envelope schema ... should that be removed? The WSDL still references s12:Fault in CreateActivityResponseType. Is this intentional? -- Chris On 29/9/06 12:59, "Richard Ciapala" <richci@microsoft.com> wrote:
Hi,
At this AM's SC06 interop demo conf call, we decided to change the response messages that use the s12:Fault type to xsd:anyType as a interim solution so we can proceed with the interop testing. Glenn had sent a separate email out regarding this issue earlier in the week. We also need to discuss a longer term solution within the context of the BES working group.
I attached the updated bes-factory.xsd so Peter's WSDL + this XSD (derived from Peter's) are the latest versions for the demo at this time.
Thanks
-----Original Message----- From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Peter Lane Sent: Thursday, September 28, 2006 8:05 PM To: Glenn Wasson Cc: ogsa-hpcp-wg@ggf.org; ogsa-bes-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] wsdl/xsd modifications for BES v26
On Sep 28, 2006, at 10:22 AM, Glenn Wasson wrote:
Hello,
As part of the HPC Profile interop work, I have been trying to process the BES v26 WSDL through my tooling (Microsoft's wsdl.exe). I have found a number of problems with the BES-Factory wsdl and xsd that appears in the appendix of the BES document. Some of these issues are simple typos and some require re-formulations of the wsdl/xsd in order to work with the tooling. I have attached modified versions of both the wsdl and xsd for bes-factory and, below, I have provided a summary of the changes. I contend that these changes (apart from fixing typos) don't actually change the defined interface/data types - they are merely an alternate way of expressing the same ideas using wsdl/xsd that (at least my) tooling can handle.
I am interested in: a) comments on this reformulation b) whether anyone else, who is using different tools, has had similar (or different) issues with the wsdl/xsd in the BES v26 appendix c) whether anyone using different tools encounters issues processing the attached wsdl/xsd d) whether people participating in the HPCP interop work are willing to use the attached wsdl/xsd
Glenn
Summary of changes: 1. bes-factory wsdl (appendix E) and bes-factory xsd (appendix B) both have
<xsd:schema> elements with the same target namespace - moved schema types from bes-factory.wsdl to bes-factory.xsd
I disagree with this change. Unless we think someone will need to import the message types, they aren't relevant anywhere except within the WSDL and should remain there.
- changed <schema> element in bes-factory.wsdl to only import bes- factory.xsd (other imports seemed to create problems because the same
schemas were also imported in the bes-factory.xsd file) - changed target namespace of <xsd:schema> element in bes- factory.wsdl to http://schemas.ggf.org/bes/2006/08/bes-factory/WSDL (added the /WSDL) - This doesn't effect anything since no types are defined in the bes- factory.wsdl's <xsd:schema>, but was necessary to prevent the namespace collision
This should be an xsd:include, then, not an xsd:import:
<xsd:include schemaLocation="bes-factory.xsd"/>
No need to hack a namespace into the WSDL's schema section...
2. the operation "ResponseType" elements are multiply defined - both the wsdl and xsd define <xsd:element>s for, for example, CreateActivityResponse (the definitions differ only in the name of an
outer element wrapper) - kept the definition with the outer element wrapper around the type (i.e. <Response> as the outer element)
The types weren't the same at all. One set was the single-activity type which is then referenced in the multi-activity type that is actually used in the BES factory operation messages.
- moved this definition to bes-factory.xsd and simply reference it from
bes-factory.wsdl 3. typos in the types of the response elements for several operations - GetActivityStatusesResponse, TerminateActivitiesResponse, GetActivityDocumentsResponse should be of types GetActivityStatusesResponseType, TerminateActivitiesResponseType, GetActivityDocumentsResponseType respectively 4. added minOccurs and maxOccurs to the GetAttributesDocument related classes - spec seems undecided here
I fixed the things I commented on above and am attaching new versions of these two files. I've also validated them with the GT tooling.
Peter
<bes-factory.xsd> <bes-factory.wsdl> -- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
participants (4)
-
Christopher Smith -
Glenn Wasson -
Peter Lane -
Richard Ciapala