Registry Interface WSDL style

[Matthew J. Graham]

Hi,

This looks fine.

The default setting in XML Schema is minOccurs=1, maxOccurs=1 so if you 
want just no or one appearance of an element allowable, you just need 
to specify minOccurs=0; of course, if you want to explicit and human 
readable, it does not change anything to add the maxOccurs=1.

	Cheers,

	Matthew


On Nov 15, 2004, at 1:26 AM, Kevin Benson wrote:

> You are correct Matthew, this should be changed like you said.  I 
> suspect I wrote the Apache Axis code as a "Wrapped" coding style which 
> of course places the operation name inside the soap body autmatically. 
>  But the wsdl should reflect this as well.  Matthew if you can, please 
> confirm what I have below is the correct way.
> On another note to make things easier with an OAI response, I would 
> like the new WSDL to just return the <OAI-PMH> element. Unless there 
> are objections?  Ray and I talked about this recently and it does make 
> things easier and to reuse other OAI components/http that may be 
> already there. The only downside is it would be possible to return 
> something like an Identify for a ListRecords request. If you think 
> this downside is reason enough to not do this, then e-mail to the 
> list.
>
> For the time being I will  add a new wsdl to the wiki site later on 
> this afternoon reflecting the Wrapped style in the wsdl. As for the 
> response on the OAI, I shall go ahead and put 2 versions down at the 
> moment and let registry ivoa list pick out the preference.
>
> Thanks,
> Kevin
>
> If possible confirm, the new wsdl style should always be something 
> like this on all our methods.  (The response should also follow a 
> similiar pattern having a "<operationname>Response" as part of the 
> return.)  Sorry namespace/prefix might be a little off, but you get 
> the idea from the sample:
>       <operation name="ListIdentifiers">
>          <input message="tns:ListIdentifiersRequest"/>
>          <output message="tns:ListIdentifiersResponse"/>
>          <fault name="ListIdentifiersError" 
> message="tns:ErrorResponse"/>
>       </operation>
>
>    <message name="ListIdentifiersRequest">
>       <part name="ListIdentifiers" type="tns:ListIdentifiers"/>
>    </message>
>
>    <message name="ListIdentifiersResponse">
>       <part name="ListIdentifiersResponse" 
> type="tns:ListIdentifiersResponse"/>
>    </message>
>
>
> <element name="ListIdentifiers">
> <complexType>
> 	<sequence>
>  		<element minOccurs="0" maxOccurs="1" name="qualifiers" 
> type="tns:RequestQualifiers" />
> 		<element minOccurs="1" maxOccurs="1" name="metadataPrefix" 
> type="xs:string" />
> 	</sequence>
> </complexType>
> </s:element>
>
> <element name="ListIdentifiersResponse">
> <complexType>
> 	<sequence>
>  		<element minOccurs="0" maxOccurs="1" name="qualifiers" 
> type="tns:OAI-PMH" />
> 	</sequence>
> </complexType>
> </s:element>
>
>
>
>
> On Fri, 12 Nov 2004, Matthew J. Graham wrote:
>
>> Hi,
>>
>> I am trying to generate an instance of a SOAP message from the 
>> Registry Interface WSDL and was wondering what style it's supposed to 
>> be? The binding suggests doc/literal but if this is the case, the 
>> message elements should be:
>>
>> <message name="...">
>>  <part name="..." element="..."/>
>> </message>
>>
>> and there would be no way of determining what the operation name 
>> should be. The way it is as the moment means I could send two SOAP 
>> messages (valid according to the WSDL):
>>
>> <SOAP:Body>
>>  <fish> this is of type RequestQualifier </fish>
>>  <paste> this is the metadataPrefix </paste>
>> </SOAP:Body>
>>
>> and
>>
>> <SOAP:Body>
>>  <fish> this is of type RequestQualifier </fish>
>>  <paste> this is the metadataPrefix </paste>
>> </SOAP:Body>
>>
>> where the first is calling ListIdentifiers and the second ListRecords.
>>
>> If it is doc/literal wrapped (so that the operation name appears as 
>> the enclosing element in the SOAP body) then:
>> - input and output messages must contain only one part so some of the 
>> requests will need to be modified, e.g. keyword search
>> - the part in the input message refers to an element named after the 
>> operation
>>
>> 	Cheers,
>>
>> 	Matthew
>>
>>