OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [regrep] WSDL Issues


Matt,

Just to let you know -- I'm mostly a lurker on this list, but I'm happy to
help when requested. Farrukh sent me a note this morning asking me to review
the WSDL. So I did. No offense intended toward you. WSDL is a nasty beast,
and I don't expect most people to know all it's nuances. Also, I'm not a
member of WS-I, either, but I recognize it's value, and I firmly expect that
its recommendations will be adopted as the standard. Interoperability is a
hard nut to crack, and the WS-I BP defines a set of constraints on SOAP,
WSDL, and UDDI that should alleviate a lot of pain.

I'll be happy to mock up the WSDL for you, but first I need you to answer my
question about the partContent parameter. What is this parameter used for,
and why isn't it included in the message element? Am I correct that it does
need to be included in the three messages, and that it should follow the
primary message element?

Also, I wasn't proposing that we duplicate the schema information -- only
that we define a <types> section and import the schemas into that section
rather than as a direct child of <definitions>. Per the WSDL schema, a
<schema> element can be a child of <types>, but not a child of
<definitions>. (Hence the WS-I BP constraint.) We can do that either in a
separate WSDL file or in the Abstract WSDL file.

I would definitely suggest that you define at least one SOAP Fault
message -- a basic error disposition report. For an example, I suggest you
look at the UDDI WSDL files [1, 2].

In any case, I'll mock up some suggestions and send it along presently.

Anne

[1] http://uddi.org/wsdl/inquire_v2.wsdl
[2] http://uddi.org/wsdl/publish_v2.wsdl

----- 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
> >
> >
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]