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

20 Oct 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@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