Extending Abstract Data Types for XML Payloads in SOAP Doc/Lit Messages

[Tony Opatha <to...@yahoo.com>]

I am using AXIS 1.1 to develop web services that require interoperation with .NET 1.1 and Java clients (that may run on different Java/SOAP client run-times using Doc/Lit
SOAP binding.
 
The message payload that is used to instantiaite the particular payload instances
for the SOAP message actually is based on extending an abstract data type.

<xs:complexType name="AbstractDocType" abstract="true"> <xs:element name="ElementA" type="xs:string"/> <xs:element name="ElementB" type="xs:string"/> <xs:any processContents="lax" minOccurs="0"/> </xs:sequence> </xs:complexType>

The abstract data type can potentially allow the concrete data type (which is
used to create the particular payload i.e., document instance for the SOAP message body) to potentially carry any type of data, i.e., from any namespace.
 
When I try to test with .NET 1.1 client such XML schema is successfully processed
(i.e., .NET WSDL.exe compiler accepts it and can serialize and de-serialize) and
also AXIS Java2WSDL can process it successfully. Furthermore, the SOAPScope
accepts the XML schema to be WS-I BP 1.0a compliant.
 
However, it seems that this type of schema design where we have <xs:any> embedded
in the abstract data type can be considered by some XML processors to be illegal since
it can allow data from some bogus namespace included and violate unique particle attribution rule. However, it seems that WS-I BP Profile does not seem to disallow this.
 
To get around this would it be better to replace 
 
<xs:any processContents="lax" minOccurs="0"/> 

by following <xs:any> declaration

<xs:any processContents="skip" minOccurs="0" namespace="foo"/>

I would prefer that we use the <xs:any> with lax processing rather than skip
processing directive. 
 
Is this approach acceptable from a AXIS 1.2 WS-I BP 1.0a compliance standpoint?
 

Thanks.



		
---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th