Re: [regrep] WSDL Issues

["Anne Thomas Manes" <anne@manes.net>]

Here's my mock up of the two WSDL files. I haven't tested them.

In registry-abstract, I added a <types> section. In it I imported the three
schemas, and I defined complex types and elements for the three messages
that contain the extra Content part. Also defined an element called
dispositionReport for an error message. Currently it's defined as a simple
xsd:string, but I assume that you would like to define a formatted error
message.

I changed the first three <message>s to reference the new elements that
contain the Content part.
I renamed all the parts to "body".
I added a message called dispositionReport.
I added <fault>s to each <operation>.
I changed the tns qualifier to registry-abstract throughout.
I tidied up the namespace declarations.

In registry-soap, I changed all operations to style="document"
I added <fault>s to each <operation>.
I added the parts attribute to each <input> and <output>.
I simplified the soapAction parameters.
I tidied up the namespace declarations.

I think that's all.

Best regards,
Anne

----- Original Message -----
From: "Matthew MacKenzie" <matt@yellowdragonsoft.com>
To: "Anne Thomas Manes" <anne@manes.net>
Cc: "Farrukh Najmi" <farrukh.najmi@sun.com>; <regrep@lists.oasis-open.org>
Sent: Tuesday, June 24, 2003 7:07 PM
Subject: Re: [regrep] WSDL Issues


> Anne,
>
> The WSDL was put up for review months ago, and it would have been great
> if you asserted this criticism then.  Since you seem to be up on WSDL,
> I'd be happy if you'd help out by mocking up some better WSDL.
>
> My blanket answers (from general to specific):
>
> 1) I have no inclination toward adding the title "WSDL Guru" to my CV.
> I just used the spec and examples in the spec to get where I was going.
> 2) WS-I is a club I don't belong to, and no one gave me the requirement
> that ebRR WSDL must support/comply with WS-I work output.
> 3) The only person who tested the WSDL did so with the .NET tools and
> gave me input which was incorporated into the final version.  I used my
> text editor plus 2 commonly available WSDL tools while authoring the
> WSDL (Cape Clear and XML Spy), and that is all I could do with the time
> I had to donate to the work.
> 4) You (and WS-I's BP) propose an awful way of getting around schema
> imports.  Its not practical to maintain the ebRS/RIM types in two
> places.  If the BP suggests what you say, I suggest its not really the
> best practice.
> 5) No soap faults because we just wanted to keep things simple by using
> RegistryError in a straightforward way.  Maybe we can revisit that...I
> left it as is because I hadn't seen faults defined in the old WSDL.
>
> -Matt
>
> Anne Thomas Manes wrote:
>
> >Some questions and comments:
> >
> >(1) Per the WS-I BP, you should use wsdl:import to import only WSDL
files,
> >not XSD files. To import XSD files, you should create a <types> section
and
> >use xsd:import to import the schemas. You can do this in one of two ways.
> >Either you can create another WSDL file that just contains the <types>
> >section (containing the imported schemas) and then import this types WSDL
> >into the abstract WSDL, or you can add a <types> section to the abstract
> >WSDL.
> >
> >(2) This WSDL is designed to use document/literal -- all your messages
(for
> >the most part) refer to elements (element=) rather than parameters
(type=).
> >But I have noticed that you mix <part>s in three messages
> >(msgRegistryResponse, msgUpdateObjectsRequest, and
msgSubmitObjectsRequest
> >messages). These messages include two <parts> -- a message element
> >(different for each one) and a parameter (<part name="partContent"
> >type="xsd:string"/> -- the same for each one). What is the purpose of the
> >partContent parameter? I don't see it (or any other parts) referenced by
any
> ><binding> elements.
> >
> >If partContent is required to be included in the input message, why is it
> >not included in the message structure?  Also, keep in mind that WS-I BP
> >permits only one <part> on document/literal messages, so to be WS-I
> >compliant, you would have to include it in the message structure.
> >
> >One reason why you might want to define multiple parts in a message
> >definition is to define header or headerfault messages (which should
always
> >be defined as document/literal) -- but in that case you should always
> >reference the specific part to be used in the <binding> elements. e.g.:
> >
> >   <message name='foo'>
> >      <part name='body' element='foobody' />
> >      <part name='header' element='fooheader' />
> >      <part name='headerfault' element='fooheaderfault' />
> >   </message>
> >
> >   <soap:body parts='body' use='literal' />
> >   <soap:header message='tns:foo' part='header' use='literal' />
> >   <soap:headerfault message='tns:foo' part='headerfault' use='literal'
/>
> >
> >Bottom line: the three messages containing partContent have to be fixed.
> >
> >(3) I'm surprised that you haven't defined any fault messages. I suspect
> >this is an oversight.
> >
> >(4) You aren't consistent in you namespace prefixes in your abstract and
> >soapservice WSDL files. In the asbtract WSDL you refer to the XSD
namespaces
> >as lcm:, query:, and rs:, but in the soapservice WSDL you refer to them
as
> >import1:, import2:, and import3:, respectively. I suggest you change the
> >namespace prefixes in the soapservice WSDL file to the ones used in the
> >abstract WSDL. (Not that it really matters -- your don't reference any of
> >the XSD definitions in the soapservice WSDL.)
> >
> >(5) In your bindings you should specify style='document'.
> >
> >(6) In your bindings you specify a SOAPAction. I suggest for a normative
> >standard you do not want to specify a SOAPAction. (At the very least you
> >should remove "capeconnect" from the URI and specify an oasis URN)
> >
> > (7) You should remove the <service> definition from the normative
> >specification. A <service> refers to a specific implementation.
> >
> >Best regards,
> >Anne
> >
> >----- Original Message -----
> >From: "Farrukh Najmi" <farrukh.najmi@sun.com>
> >To: "Anne Thomas Manes" <anne@manes.net>
> >Cc: <regrep@lists.oasis-open.org>; "matt" <matt@yellowdragonsoft.com>
> >Sent: Tuesday, June 24, 2003 10:21 AM
> >Subject: Re: [regrep] WSDL Issues
> >
> >
> >
> >
> >>Anne Thomas Manes wrote:
> >>
> >>
> >>
> >>>I have to ask why you elected to use rpc/literal. Very few SOAP
> >>>implementations currently support rpc/literal. Why not just use
> >>>document/literal?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>Hi Anne,
> >>
> >>I think it was an oversight. I agree with your suggestion that
> >>document/literal is a better fit.
> >>
> >>Would it be possible for you to contribute a list of specific
> >>suggestions for improvement in the WSDL? This would be a valuable input
> >>to our work for V3.
> >>
> >>--
> >>Farrukh
> >>
> >>
> >>
> >>You may leave a Technical Committee at any time by visiting
> >>
> >>
>
>http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup
.
> >php
> >
> >
> >
> >
> >You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.
php
> >
> >
>
ÿþ<?xml version="1.0" encoding="UTF-8"?>

<definitions name="ebXMLRegistrySOAPService" 

   targetNamespace="urn:oasis:names:tc:ebxml-regrep:registry-soap:wsdl:2.5" 

   xmlns="http://schemas.xmlsoap.org/wsdl/" 

   xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:lcm:xsd:2.5" 

   xmlns:query="urn:oasis:names:tc:ebxml-regrep:query:xsd:2.5" 

   xmlns:rs="urn:oasis:names:tc:ebxml-regrep:rs:xsd:2.5" 

   xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime" 

   xmlns:registry-types="urn:oasis:names:tc:ebxml-regrep:registry-types:wsdl:2.5" 

   xmlns:registry-abstract="urn:oasis:names:tc:ebxml-regrep:registry-abstract:wsdl:2.5" 

   xmlns:registry-soap="urn:oasis:names:tc:ebxml-regrep:registry-soap:wsdl:2.5"

   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 

   xmlns:tns="urn:oasis:names:tc:ebxml-regrep:registry-soap:wsdl:2.5" 

   xmlns:xsd="http://www.w3.org/2001/XMLSchema" 

   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

	<documentation>

$Header: /cvsroot/ebxmlrr/ebxmlrr-spec/misc/2.5/services/ebXMLRegistrySOAPService.wsdl,v 1.1 2003/06/05 16:03:29 farrukh_najmi Exp $

Author: Matt MacKenzie

This is the the normative SOAP binding in WSDL for the OASIS ebXML Registry services.

It relies on ebXMLRegistryAbstractService.wsdl for types, messages, and portTypes.

	</documentation>



   <import namespace="urn:oasis:names:tc:ebxml-regrep:registry-abstract:wsdl:2.5"

location="http://www.oasis-open.org/committees/regrep/documents/2.5/services/ebXMLRegistryAbstractService.wsdl" />



	<binding name="QueryManagerBinding" type="registry-abstract:QueryManagerPortType">

		<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

		<operation name="getContent">

			<soap:operation soapAction="getContent" style="document"/>

			<input>

				<soap:body parts="body" use="literal"/>

			</input>

			<output>

				<soap:body parts="body" use="literal"/>

			</output>

                  <fault name="error">

                        <soap:fault name="error" use="literal"/>

                  </fault>

		</operation>

		<operation name="submitAdhocQuery">

			<soap:operation soapAction="submitAdhocQuery" style="document"/>

			<input>

				<soap:body parts="body" use="literal"/>

			</input>

			<output>

				<soap:body parts="body" use="literal"/>

			</output>

                  <fault name="error">

                        <soap:fault name="error" use="literal"/>

                  </fault>

		</operation>

		<operation name="getNotifications">

			<soap:operation soapAction="getNotifications" style="document"/>

			<input>

				<soap:body parts="body" use="literal"/>

			</input>

			<output>

				<soap:body parts="body" use="literal"/>

			</output>

                  <fault name="error">

                        <soap:fault name="error" use="literal"/>

                  </fault>

		</operation>

	</binding>

	<binding name="LifeCycleManagerBinding" type="registry-abstract:LifeCycleManagerPortType">

		<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

		<operation name="addSlots">

			<soap:operation soapAction="addSlots" style="document"/>

			<input>

				<soap:body parts="body" use="literal"/>

			</input>

			<output>

				<soap:body parts="body" use="literal"/>

			</output>

                  <fault name="error">

                        <soap:fault name="error" use="literal"/>

                  </fault>

		</operation>

		<operation name="approveObjects">

			<soap:operation soapAction="approveObjects" style="document"/>

			<input>

				<soap:body parts="body" use="literal"/>

			</input>

			<output>

				<soap:body parts="body" use="literal"/>

			</output>

                  <fault name="error">

                        <soap:fault name="error" use="literal"/>

                  </fault>

		</operation>

		<operation name="deprecateObjects">

			<soap:operation soapAction="deprecateObjects" style="document"/>

			<input>

				<soap:body parts="body" use="literal"/>

			</input>

			<output>

				<soap:body parts="body" use="literal"/>

			</output>

                  <fault name="error">

                        <soap:fault name="error" use="literal"/>

                  </fault>

		</operation>

		<operation name="removeObjects">

			<soap:operation soapAction="removeObjects" style="document"/>

			<input>

				<soap:body parts="body" use="literal"/>

			</input>

			<output>

				<soap:body parts="body" use="literal"/>

			</output>

                  <fault name="error">

                        <soap:fault name="error" use="literal"/>

                  </fault>

		</operation>

		<operation name="removeSlots">

			<soap:operation soapAction="removeSlots" style="document"/>

			<input>

				<soap:body parts="body" use="literal"/>

			</input>

			<output>

				<soap:body parts="body" use="literal"/>

			</output>

                  <fault name="error">

                        <soap:fault name="error" use="literal"/>

                  </fault>

		</operation>

		<operation name="submitObjects">

			<soap:operation soapAction="submitObjects" style="document"/>

			<input>

				<soap:body parts="body" use="literal"/>

			</input>

			<output>

				<soap:body parts="body" use="literal"/>

			</output>

                  <fault name="error">

                        <soap:fault name="error" use="literal"/>

                  </fault>

		</operation>

		<operation name="updateObjects">

			<soap:operation soapAction="updateObjects" style="document"/>

			<input>

				<soap:body parts="body" use="literal"/>

			</input>

			<output>

				<soap:body parts="body" use="literal"/>

			</output>

                  <fault name="error">

                        <soap:fault name="error" use="literal"/>

                  </fault>

		</operation>

	</binding>

</definitions>

ÿþ<?xml version = "1.0" encoding = "UTF-8"?>



<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" 

    xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime" 

    xmlns:query="urn:oasis:names:tc:ebxml-regrep:query:xsd:2.5" 

    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:rs:xsd:2.5"

    xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:lcm:xsd:2.5" 

    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 

    xmlns:xsd="http://www.w3.org/2001/XMLSchema" 

    xmlns:registry-types="="urn:oasis:names:tc:ebxml-regrep:registry-types:wsdl:2.5"

    xmlns:registry-abstract="urn:oasis:names:tc:ebxml-regrep:registry-abstract:wsdl:2.5" 

    targetNamespace="urn:oasis:names:tc:ebxml-regrep:registry-abstract:wsdl:2.5" 

    name="ebXMLRegistryAbstractService">



	<documentation>

$Header: /cvsroot/ebxmlrr/ebxmlrr-spec/misc/2.5/services/ebXMLRegistryAbstractService.wsdl,v 1.1 2003/06/04 21:31:40 farrukh_najmi Exp $

Author: Matt MacKenzie

This is the the normative abstract service definition in WSDL for the OASIS ebXML Registry services.



This WSDL file defines the types, messages, and portTypes needed to communicate with a compliant 

ebXML Registry.  It is abstract in that it does not define the bindings.  Examples

of suitable bindings are defined in ebXMLRegistrySOAPService.wsdl.



This document is maintained by Matthew MacKenzie (matt@mac-kenzie.net), who does not offer any

warranty or guarantee for this file.  A general lack of solid support for SOAP with Attachments

among current WSDL tools has made it difficult to verify all of the definitions here.

	</documentation>



      <types>

         <xsd:schema targetNamespace="urn:oasis:names:tc:ebxml-regrep:registry-types:wsdl:2.5"

            xmlns:registry-types="urn:oasis:names:tc:ebxml-regrep:registry-types:wsdl:2.5"

            xmlns:query="urn:oasis:names:tc:ebxml-regrep:query:xsd:2.5" 

            xmlns:rs="urn:oasis:names:tc:ebxml-regrep:rs:xsd:2.5"

            xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:lcm:xsd:2.5" 

            xmlns:xsd="http://www.w3.org/2001/XMLSchema">



            <!-- Import the rs.xsd. -->

	      <xsd:import namespace="urn:oasis:names:tc:ebxml-regrep:rs:xsd:2.5"

		  location="http://www.oasis-open.org/committees/regrep/documents/2.5/schema/rs.xsd"/>



            <!-- Import the lcm.xsd. -->

            <xsd:import namespace="urn:oasis:names:tc:ebxml-regrep:lcm:xsd:2.5"

              location="http://www.oasis-open.org/committees/regrep/documents/2.5/schema/lcm.xsd"/>



            <!-- Import the query.xsd. -->

            <xsd:import namespace="urn:oasis:names:tc:ebxml-regrep:query:xsd:2.5"

              location="http://www.oasis-open.org/committees/regrep/documents/2.5/schema/query.xsd"/>



            <xsd:element name="msgRegistryResponse" type="registry-types:RegistryResponsewContent"

            <xsd:complexType name="RegistryResponsewContent"

              <xsd:sequence>

                <xsd:element ref="rs:RegistryResponse" minOccurs="0" maxOccurs="1"/>

                <xsd:element name="Content" type="xsd:string" minOccurs="0" maxOccurs="1"/>

              </xsd:sequence>

            </xsd:complexType>



            <xsd:element name="msgUpdateObjectsRequest" type="registry-types:UpdateObjectsRequestwContent"

            <xsd:complexType name="UpdateObjectsRequestwContent"

              <xsd:sequence>

                <xsd:element ref="lcm:UpdateObjectsRequest" minOccurs="0" maxOccurs="1"/>

                <xsd:element name="Content" type="xsd:string" minOccurs="0" maxOccurs="1"/>

              </xsd:sequence>

            </xsd:complexType>



            <xsd:element name="msgSubmitObjectsRequest" type="registry-types:SubmitObjectsRequestwContent"

            <xsd:complexType name="SubmitObjectsRequestwContent"

              <xsd:sequence>

                <xsd:element ref="lcm:SubmitObjectsRequest" minOccurs="0" maxOccurs="1"/>

                <xsd:element name="Content" type="xsd:string" minOccurs="0" maxOccurs="1"/>

              </xsd:sequence>

           </xsd:complexType>



            <xsd:element name="dispositionReport" type="xsd:string"

            <!-- I assume that you would like to define the format of your disposition report -->



         </xsd:schema>

      </types>



	<!-- The Response message definition. -->

	<message name="msgRegistryResponse">

		<documentation>Defines a RegistryResponse message.</documentation>

		<part name="body" element="registry-types:msgRegistryResponse"/>

	</message>



	<!-- Request message definitions. -->

	<message name="msgUpdateObjectsRequest">

		<part name="body" element="registry-types:msgUpdateObjectsRequest"/>

	</message>



	<message name="msgSubmitObjectsRequest">

		<part name="body" element="registry-types:msgSubmitObjectsRequest"/>

	</message>



	<message name="msgDeprecateObjectsRequest">

		<part name="body" element="lcm:DeprecateObjectsRequest"/>

	</message>



	<message name="msgGetContentRequest">

		<!-- w query -->

		<part name="body" element="query:GetContentRequest"/>

	</message>



	<message name="msgAddSlotsRequest">

		<part name="body" element="lcm:AddSlotsRequest"/>

	</message>



	<message name="msgRemoveSlotsRequest">

		<part name="body" element="lcm:RemoveSlotsRequest"/>

	</message>



	<message name="msgRemoveObjectsRequest">

		<part name="body" element="lcm:RemoveObjectsRequest"/>

	</message>



	<message name="msgApproveObjectsRequest">

		<part name="body" element="lcm:ApproveObjectsRequest"/>

	</message>



	<message name="msgAdhocQueryRequest">

		<part name="body" element="query:AdhocQueryRequest"/>

	</message>



	<message name="msgGetNotificationsRequest">

		<part name="body" element="query:GetNotificationsRequest"/>

	</message>



      <message name="dispositionReport">

            <part name="body" element="registry-types:dispositionReport"/>

      </message>

	

	<!-- Port Types 

	     A port type is a piece of markup which defines a class of methods, or in WSDL

	     nomenclature, operations.  In object-oriented-ese, a portType maps to a class, and

	     an operation maps to a method.

	     

	     Each operation has an input message and an output message. 

	-->

	<portType name="QueryManagerPortType">

		<operation name="getContent">

			<input message="registry-abstract:msgGetContentRequest"/>

			<output message="registry-abstract:msgRegistryResponse"/>

                  <fault name="error" message="registry-abstract:dispositionReport"/>

		</operation>

		<operation name="submitAdhocQuery">

			<input message="registry-abstract:msgAdhocQueryRequest"/>

			<output message="registry-abstract:msgRegistryResponse"/>

                  <fault name="error" message="registry-abstract:dispositionReport"/>

		</operation>

		<operation name="getNotifications">

			<input message="registry-abstract:msgGetNotificationsRequest"/>

			<output message="registry-abstract:msgRegistryResponse"/>

                  <fault name="error" message="registry-abstract:dispositionReport"/>

		</operation>



	</portType>



	<portType name="LifeCycleManagerPortType">

		<operation name="addSlots">

			<input message="registry-abstract:msgAddSlotsRequest"/>

			<output message="registry-abstract:msgRegistryResponse"/>

                  <fault name="error" message="registry-abstract:dispositionReport"/>

		</operation>

		<operation name="approveObjects">

			<input message="registry-abstract:msgApproveObjectsRequest"/>

			<output message="registry-abstract:msgRegistryResponse"/>

                  <fault name="error" message="registry-abstract:dispositionReport"/>

		</operation>

		<operation name="deprecateObjects">

			<input message="registry-abstract:msgDeprecateObjectsRequest"/>

			<output message="registry-abstract:msgRegistryResponse"/>

                  <fault name="error" message="registry-abstract:dispositionReport"/>

		</operation>

		<operation name="removeObjects">

			<input message="registry-abstract:msgRemoveObjectsRequest"/>

			<output message="registry-abstract:msgRegistryResponse"/>

                  <fault name="error" message="registry-abstract:dispositionReport"/>

		</operation>

		<operation name="removeSlots">

			<input message="registry-abstract:msgRemoveSlotsRequest"/>

			<output message="registry-abstract:msgRegistryResponse"/>

                  <fault name="error" message="registry-abstract:dispositionReport"/>

		</operation>

		<operation name="submitObjects">

			<input message="registry-abstract:msgSubmitObjectsRequest"/>

			<output message="registry-abstract:msgRegistryResponse"/>

                  <fault name="error" message="registry-abstract:dispositionReport"/>

		</operation>

		<operation name="updateObjects">

			<input message="registry-abstract:msgUpdateObjectsRequest"/>

			<output message="registry-abstract:msgUpdateObjectsRequest"/>

                  <fault name="error" message="registry-abstract:dispositionReport"/>

		</operation>

	</portType>

</definitions>