[ogsa-hpcp-wg] Another Problem (maybe?) in the WSDL

Peter G. Lane lane at mcs.anl.gov
Fri Oct 20 17:41:55 CDT 2006


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 at mcs.anl.gov] 
>> Sent: Friday, October 20, 2006 5:04 PM
>> To: Mark Morgan
>> Cc: ogsa-hpcp-wg at 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
>>
>> Mark Morgan wrote:
>>> In trying to interop with Glenn's endpoint, I have found another 
>>> potential problem with the BES-Factory's WSDL.  However, 
>> the problem 
>>> 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 
>> the problem declarations).
>>> 	<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 
>> 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 at virginia.edu
>>> (434) 982-2047
>>>
>>> --
>>>   ogsa-hpcp-wg mailing list
>>>   ogsa-hpcp-wg at ogf.org
>>>   http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
>>>
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3804 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/ogsa-hpcp-wg/attachments/20061020/99804c48/attachment.bin 


More information about the ogsa-hpcp-wg mailing list