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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

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

Subject: RE: [wsrp-wsia] [I#93] Payload extensibility mechanism

In order to use <any namespace="##other"/> we would need to switch 
to "document style" for our wsdl (with literal encoding).
A quick check against the attached service1.wsdl showed that 
.NET and Axis compiled this test ok but Sun's JAXRPC gave up and 
passed everything as an javax.xml.soap.SOAPElement blob.
The question then becomes one of XML extensibility versus using 
SOAP rpc encoding style. [Document style would also facilitate 
returning XML markup within the getMarkup response "document" -
but I see many arguments for sticking with Section 5 SOAP Encoding.]

-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: 19 September 2002 06:47
To: wsrp-wsia@lists.oasis-open.org
Subject: [wsrp-wsia] [I#93] Payload extensibility mechanism

Topic:  interface
Class:  Minor Technical
Title:  Payload extensibility mechanism
Document Section: throughout
Current draft spec uses Property[] as a payload extension mechanism. At the
F2F we decided to explore changing this to the <any/> mechanism of schema.
Richard Cieply did some testing based on the working demo he showed and
some exploration around the relevant specs. His writeup:

Here is a short summary about the <any> support in WSDL and the SOAP

   WSDL spec 1.1 and 1.2 doesn't mention the <any> XML extension and how to
   deal with it.
   However it states that WSDL prefers XSD as the canonical type system.
   XSD defines the <any> wild card.
   SOAP 1.1 spec states that it defines a narrower set of rules for
   encoding data (than XML does).
   Section 5 defines some value, simple value, compound value, array,
   struct, simple type, compound type.
   However this deals with how content must be encoded in a SOAP message.
   For the <any> case one would exchange this wildcard with actual content
   which follows the spec, i.e. one can not say whether <any> is supported
   or not.
   JAX RPC has an XML schema support appendix and states that  any XML data
   types not listed in this section are not required to be supported.
   How to deal with <any> is not mentioned here.

   I made some testing with AXIS and .NET
      created a WSDL extending a complex type (DataItem) with <any
      (See attached file: echo.wsdl)
      used AXIS' WSDL2Java to generate the server side stub
      AXIS created a field named _any to DataItem with type
      org.apache.axis.message.MessageElement [ ]
      created a client side wsdl which replaced the <any> element with some
      additional elements to get a client proxy which sends addtional data
      in DataItem in the soap message
      (See attached file: echoclient.wsdl)
      communication between client and server worked as expected
      the addtional elements were accessible by means of the MessageElement
      [ ] on the server side. Of course this would also work vice versa.

      MS Visual Studion .NET failed to generate proxies on a WSDL
      containing <any> with no error message. Simply no code was generated
      at all.
      WSDL.exe from the .netFrameworkSDK failed saying that any is not
      allowed in the WSDL.
      I could not find any statement saying whether .net should support
      <any> in WSDL or not

      However a .net server accepts a soap message which contains
      additional elements compared to the ones defined in the wsdl (as
      There should be a way to access the complete soap message from .net.
      So there might be a workaround by simply dropping the <any> elements
      in the WSDL (when creating a service from a WSDL) and access the soap
      message to obtain the addtional data sent by the client (not tried).

Attachment: service1.wsdl
Description: Binary data

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

Powered by eList eXpress LLC