Issues for CORBA-WSDL/SOAP Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 5785: CORBA-WSDL/SOAP: Section 1.2.2.1
Issue 5786: CORBA-WSDL/SOAP: Section 1.2.3
Issue 5787: Section 1.2.3 repository id inconsistency
Issue 5788: CORBA-WSDL/SOAP: section 1.2.4
Issue 5790: CORBA-WSDL/SOAP: Section 1.2.7.10
Issue 5791: CORBA-WSDL/SOAP: Section 1.2.7.10.3
Issue 5792: CORBA-WSDL/SOAP: section 1.2.8.2 , 1.2.8.4 and 1.2.8.5
Issue 5793: CORBA-WSDL/SOAP: Section 1.2.7.4
Issue 6613: CORBA fixed types
Issue 6994: 'CORBA to WSDL/SOAP Section 1.2.8.2
Issue 6995: 'CORBA to WSDL/SOAP: example for operation mapping
Issue 6996: CORBA to WSDL/SOAP: example for attributes mapping

Issue 5785: CORBA-WSDL/SOAP: Section 1.2.2.1 (corbawsdl-ftf)

Section 1.2.2.1 -
tns is a single namespace for all mapped IDL from the entire corba
world.
The module names for IDL across this vast namespace, need to be
sufficiently qualified with pre-fixes (such as Type ID, or Pragma
Prefix) to avoid module name collisions.


Proposed Resolution: FTF needs to determine appropriate prefixes or
namespaces to assure module name uniqueness in the generated WSDL

Resolution:  

 

Append a  prefix (if present and required) in front of the module name.  

 

Need to fix all examples to use this pragma prefix in module name prefixes.

 

To avoid invalid XML element names, use “_” rather than “:” (which is reserved for use with XML namespaces) in the name prefixes

Section 1.2.3 - need to have appropriate text to describe the nature of
the source "hint".  Examples might be included, using filenames.


Proposed Resolution: FTF should determine appropriate text.

Section 1.2.3 - there is an inconsistency, in that the documentation
schema for the repository ID dos not include the version of the mapping,


as included in the URL source documentation schema.
Knowing what version of the IDL to WSDL mapping produced the WSDL is
important for gateway design.


Proposed Resolution: add mapping version to the respositoryID
documentation schema.

This is a bug.  There is also two typographical errors in the schema for IDL source

section 1.2.4 - The sentence "The most significatn is that XML flattens
the constructed namespace to a single targeted namespace when an XML
schema is imported." does not seem quite correct. Avoiding a large
number of files for the wsdl processor to deal with is a major reason
cited by the submitters.


Proposed Solution: Replace the offending sentence, with: "Having a
separate namespace for each imported module results in a large number of


files for the WSDL processor to deal with when constructing a gateway."

Section 1.2.7.10 ­
Only public state members are mapped. Since use of the Dynamic Any api
allows access to both the private
and public members, this restriction was challenged by the AB reviewer
as unwarranted.
Also the sentence "For example, DII/DSI bridges will be unable to
process value types." is not justified.


The dynamic ANY api can be used to access value type state members in a
DII/DSI based gateway.
If private state cannot be represented, an input value type parameter
which has private state will not be mapped to the IDL server.


Proposed Solution:
Delete offending sentence about dynamic gateways.
Unless the private member restriction can be justified, change the spec
to map both private and public value type state members.

Since the dynamic ANY api can be used to access all value type state members in a DII/DSI gateway, the restriction to not mapping private state members needs to be removed

Section 1.2.7.10.3 - need to represent value type in IDL sequence as an
IdRef/value choice.


Proposed Resolution:
fix spec to use the idRef/Value choice for sequence<valueType>.

Agree to bug fix.  Also need resolve editorial problems pointed out in bold by the reviewer in  ptc/3-01-14.

Resolution: include IDL sequence including a value type in the mapping algorithm generation of the IdRef/value choice type

section 1.2.8.2 , 1.2.8.4 and 1.2.8.5 - In all the Example WSDL, the
target namespace in definitions and the namespace in import using URL
"http://tempuri.org/anExample/.." do not seem correct.


Proposed Resolution: fix the example after resolving the Type prefix FTF


issue on namespace and module name uniqueness.

The mapping does not state what value should be used for the default
case.


Proposed Resolution:
Add text stating that any valid value for the discriminant, other than
those used
in the union definition, can be inserted for the default case.

CORBA fixed types are mapped to the XML Schema "decimal" type (not "integer") 

And the element "restriction" of the map becomes : <xsd:restriction base="xsd:decimal"> 


The xsd:integer type have a facet fractionDigits fixed to 0.

Section 1.2.8.2
In the example:
<message name="CORBA.SystemExceptionMessage" >
<part name="_return" type="CORBA.SystemException"/>
</message>
CORBA Specification says that CORBA Exception cannot be passed as paramters or return value. But the example seems to ¡°return¡± a SystemException.
Proposed solution: Maybe the example should be defined as the following according to the exception mapping rules:
<message name="CORBA.SystemExceptionMessage" >
<part name="exception" type="CORBA.SystemException"/>
</message>

Section 1.2.8.2
Also, in the example for operation mapping. 
<portType name="SomeInterface" >
<operation name="bar" >
<input message="tns:SomeInterface.bar"/>
<output message="tns:SomeInterface.barResponse"/>
<fault message=¡±tns:CORBA.SystemException¡±/>
</operation>
</portType>
Here defines the fault message, yet its type is not CORBA.SystemExceptionMessage defined ahead, but CORBA.SystemException, which is defined as a complextype. 
Proposed solution: Maybe the following is right:
<fault message=¡±tns:CORBA.SystemExceptionMessage¡±/>

Section 1.2.8.2
In the example for attributes mapping.
The get accessor maps to an operation with only an output message. It seems like a notification operation according to WSDL specification. But the semantics of attribute accessors should be request-response .So a get accessor should be mapped to a couple of messages.
Proposed solution :
Define the incoming message as a message without any parameter as the following:
<message name="MyAttrs._get_strAttr" />
<message name="MyAttrs._get_strAttrResponse" >
<part name="_return" type="xsd:string"/>
</message>
¡­
<portType name="MyAttrs" >
<operation name="_get_strAttr" >
<output message="tns:MyAttrs._get_strAttrResponse"/>
<fault message=¡±tns:CORBA.SystemException¡±/>
</operation>

WSDL section 2.4 states the following:
"
Although the base WSDL structure supports bindings for these four transmission primitives, WSDL only defines bindings for the One-way and Request-response primitives.  It is expected that specifications that define the protocols for Solicit-response or Notification would also include WSDL binding extensions that allow use of these primitives.
"

The basic profile from WS-I states the following:
"
4.5.2 Allowed Operations

Solicit-Response and Notification operations are not well defined by WSDL 1.1; furthermore, WSDL 1.1 does not define bindings for them.

R2303 A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition.
"

Based on this, we really should change the mapping for the get accessor for attributes to use an empty request message (i.e., no parts) rather than NO Request message.  An operation with no input message is a notification type operation, which does not have a standard wsdl binding defined.