The OMG specification [[http://www.omg.org/technology/documents/formal/WSDL_CORBA.htm|WSDL-SOAP to CORBA Interworking]] Version 1.0 (formal/04-04-01) includes several typos and formal errors. In chapter 7.4.3 (Restriction to WSDL Type System) the type //negativeInteger// missing in the list and the //PositiveInteger// item should not have the capital "P". The situation is very same in the following IDL module type definitions. In the chapter 7.4.4 (Mapping to enumerators) the authors of the specification missed one IDL limitations. It is not possible to have the same items in two or more different enums. For example if we have: <Unable to render embedded object: File (--WSDL --> <simpleType name="X" restriction base="string"> <enumeration value = "A" /> <enumeration value = "B" /> <enumeration value = "C" /> </simpleType name> <) not found.-WSDL --> <simpleType name="Y" restriction base="string"> <enumeration value = "A" /> <!error, A is already defined-> </simpleType name> As you can see it is not possible to have an A enumeration item in both X and Y enums while using IDL. We must use prefixes here – I do recommend to use //X_A, X_B, X_C and Y_A// names for enum items in this case. In the chapter 7.5 (Mapping for Complex XML Schema Types) I am missing the mapping for empty complex types. Sometimes it is useful to create empty complex types (for example empty sequence). One of our customers use empty sequences for implementing empty responses in oneway service bus operations. We have used an empty struct with a dummy wstring type which is always empty and called //T_dummy//. There is a typo in the example in 7.5.5 chapter Mapping Attributes of Complex Type: <xsd:complexType> taggedShort <xsd:simpleContent> <xsd:extension base="xsd:short"> <xsd:attribute name="type" tag="xsd:string" use="optional"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> The first line should be //<xsd:complexType name="taggedShort"// and the generated IDL example has a typo in the last type: // OMG IDL struct taggedShort

; The last type should be called "type" and not "tag". The correct version follows. // OMG IDL struct taggedShort

;

The unknown type "xsd:url" must be replaced by "xsd:anyURI" in corba.wsdl. There are 2 occurences : <element name="url" ... <element name="definition" ...

replace "xsd:url" with "xsd:anyURI" in both occurrences

Corba IDL to WSDL interworking: ptc/03-11-02

Section 1.2.8 and 1.2.9 have several example wsdl descriptions.

However, these are not in the proper format for a wsdl description.

They should be editorially fixed in the Document, and made

availalbe as informative files.

Solution Proposed by Submitter:

In Section 1.2.8 and 1.2.9 fix the wsdl descriptions to validate with the wsdl schema, and make them available as files.

The RTF chair will make these files available in time for the vote on this issue.

: Close with accepting revised text below

Corba IDL to WSDL interworking: ptc/03-11-02

Section 1.2.3: Identifying the Source IDL

The text states that the annotation elements are in the CORBA namespace.

However both schema have the wrong targetNamespace.

The erroneous schema namespace information should be deleted. Put all the corba namespace type and element definitions in a single normative schema section and file.

Solution Proposed by Submitter:

In Section 1.2.3:

On pages 1-3 and 1-4

Delete the first four lines of each schema:

“

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

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

targetNamespace="http://www.omg.org/IDL-MAPPED"

elementFormDefault="qualified" attributeFormDefault="unqualified">

“

and delete the final line of each schema:

“

</xsd:schema>

Add the following new normative schema for the CORBA namespace, gathering all the type and element definitions spread throughout the document (the schema for objectReference, from issue xxxx, is fixed in this new schema):

<?xml version="1.0" encoding="utf-8"?>

<!--

WSDL for IDL to WSDL CORBA Namespace

Name: corba.wsdl

-->

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:corba="http://www.omg.org/IDL-WSDL/1.0/" targetNamespace="http://www.omg.org/IDL-WSDL/1.0/" name="corba">

<types>

<xsd:schema targetNamespace="http://www.omg.org/IDL-WSDL/1.0/">

<xsd:element name="SourceIDL" >

<xsd:annotation>

<xsd:documentation>IDL/WSDL Mapping Info</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

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

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

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="SourceRepositoryID" >

<xsd:annotation>

<xsd:documentation>IDL Mapped Repository ID </xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

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

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

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:complexType name="ObjectReference">

<xsd:sequence>

<xsd:element name="url" type="xsd:url" minOccurs="1"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="CORBA.TypeCode">

<xsd:sequence>

<xsd:element name="definition" type="xsd:url" maxOccurs="1" minOccurs="1"/>

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

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="CORBA.Any">

<xsd:sequence>

<xsd:element name="type" type="corba:CORBA.TypeCode" maxOccurs="1" minOccurs="1"/>

<xsd:element name="value" type="xsd:anyType" maxOccurs="1" minOccurs="1"/>

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="CORBA.completion_status">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="COMPLETED_YES"/>

<xsd:enumeration value="COMPLETED_NO"/>

<xsd:enumeration value="COMPLETED_MAYBE"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:complexType name="CORBA.SystemException">

<xsd:sequence>

<xsd:element name="minor" type="xsd:unsignedInt" maxOccurs="1" minOccurs="1"/>

<xsd:element name="completion_status" type="corba:CORBA.completion_status" maxOccurs="1" minOccurs="1"/>

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

</types>

<message name="CORBA.SystemExceptionMessage">

<part name="_return" type="corba:CORBA.SystemException"/>

</message>

</definitions>

Close with accepting solution proposed by submitter

Corba IDL to WSDL interworking: ptc/03-11-02

Section 1.2.5: Object References

The text states that the object reference maps to a sequence of URLs.

However the schema has a maxOccurs=1 for the element.

Solution Proposed by Submitter:

In Section 1.2.5 change:

“

<xsd:complexType name="ObjectReference">

<xsd:sequence>

<xsd:element

name="url" type="xsd:url"

maxOccurs="1" minOccurs="1"/>

</xsd:sequence>

</xsd:complexType>

“

to

“

<xsd:complexType name="ObjectReference">

<xsd:sequence>

<xsd:element

name="url" type="xsd:url"

minOccurs="1"/>

</xsd:sequence>

</xsd:complexType>

“

Close with accepting solution proposed by submitter

In the example:
<portType name="Example.SomeInterface">
<operation name="bar" parameterOrder="_target pi">
<input message="tns:Example.SomeInterface.bar"/>
<output message="tns:Example.SomeInterface.barResponse"/>
<fault message="_exception.Example.BadRecord"/>
<fault message="_exception.Example.UnknownError"/>
<fault message=¡±tns:CORBA.SystemException¡±/>
</operation>
</portType>
Most of the WSDL2java tool will use element'name' as a parameter's name. So, on receiving the WSDL as above (page
1-25), most WSDL2java tool will report an error in process for mapping WSDL to java.

Proposed solution: Maybe we should add a 'name' attribute in the fault element. For example, consider the
following IDL:
module Example{
exception BadRecord

;
Interface SomeInterface

}
It should be mapped to:
<portType name="example.SomeInterface">
<operation name="bar" >
<input message="tns:Example.SomeInterface.bar" />
<output message="tns:Example.SomeInterface.barResonse"/>
<fault message="_exception.Wxample.BadRecord" name="badRecord"/>
<fault message="_exception.Example.UnknownError" name="error"/>
<fault message="tns:CORBA.SystemException" name="systemError"/>
</operation>
</portType>

: Accept proposed change from source

Section 1.2.8.2
In the example(Page 1-22, top), "readonly" attribute is mapped as follows:
<operation name="_get_longAttr" >
<output message="tns:MyAttrs._get_longAttrResponse"/>
<fault message=¡±tns:CORBA.SystemException¡±/>
</operation>

But in most of the SOAP specification implementations(Axis, .NET 1.1 etc.), the format like this means the

operation is a 'notify' operation.

Proposed solution: Maybe we should map as follows:

<message name=¡±longAttrRequest¡±>
</message>

<operation name=¡±_get_longAttr¡±>
<input message=¡±tns:longAttrRequest¡± />
<output message=¡±tns:MyAttrs._get_longAttrResponse¡±/>
<fault message=¡°tns:CORBA.SystemException¡±>
</operation>

Close as Duplicate of Issue 6996

In the example, bar operation defined in SomeInterface are mapped as the following:

<message name="Example.SomeInterface.bar" >

<part name="_target" type="CORBA:Reference"/>

<part name="pi" type="xsd:float"/>

</message>

But according to the mapping rule in Section 1.2.8.2, there should NOT be a ¡°_target¡± element defined in the message. Whats more, CORBA::Reference has not been defined in the specification.

Proposed solution: Please make sure that ¡°_target¡± is required or optional.

see above

The section "Typedef" needs an example with a no basic type, like following :

// IDL struct S

; typedef S S_t;

// XSD <xsd:complexType name="S"> <xsd:sequence> <xsd:element name="dummy" type="xsd:int" maxOccurs="1" minOccurs="1" /> </xsd:sequence> </xsd:complexType>

<xsd:complexType name="S_t"> <xsd:complexContent> <xsd:restriction base="tns:S"> <xsd:sequence> <xsd:element name="dummy" type="xsd:int" maxOccurs="1" minOccurs="1" /> </xsd:sequence> </xsd:restriction> </xsd:complexContent> </xsd:complexType>

Add the proposed example to the revision text

In the WS-I mapping of IDL sequence, the following element hierarchy is not valid : complexType / complexContent / sequence / element ('sequence' MUST NOT be a child of a 'complexContent')

A valid hierarchy is : complexType / sequence / element

Same issue for arrays in section 1.2.7.6.

Remove the erroneous "complexContent" level from the hierarchy for both section 1.2.7.5 and 1.2.7.6.

I was wondering if we have a problem in the spec regarding WSDL which has parts defined
with reference to schema elements, rather than shema types.
In Document-literal, the parts are defined in wsdl with reference to globally defined element defs.

Now what happens to our mapping when these globally defiined elements have anonymous types
(i.e., the element is defined inline as a complex type wihout a type name)?

Do we have a problem in this case?

Close as Duplicate of Issue 6282

A WSDL description can contain multiple namespaces, including:

• the description can have its own target namespace
• the description can use wsdl: import to import a wsdl namespace
• zero or moer schema in the types section has a target namespace (which is allowed, by WS-I profile, to be same as target namespace for the wsdl description
• The schema in a types section can use xsd:import to import multiple namespaces.

The current wsdl to corba inteworking spec only discusses the first namespace in the above list.
The specification needs to clarify that each of the multiple namespaces in the wsdl description needs
to be mapped to its own IDL module (using the same naming algorithm as currently specified for the wsdl target namespace)

Propose solution:

Amend the specification to map each namespace in the wsdl description to its own IDL module.

Close with new text mapping each target namespace to its own IDL module

With Document/Literal style/use WSDL, the message parts refer to global element declarations.

In XML schema language, these global elements definitions are allowed to be anonymous. In
such a case there is no named type for the corresponding corba operation parameter.

Proposed solution:

When required, the translator must generate a type name by adding the prefix "T_" to the name
of the element. The OMG IDL for the inteface must generate a typedef using this generated
typename

Close with the addition of prefix when required for anonymous types

Here is a new clarfication issue for the WSDL to CORBA FTF.

The subject of the WSDL/SOAP to CORBA Interworking Specification includes two subcases for a CORBA client accessing a WSDL/SOAP server instance..

One subcase (mandatory for conformance) is for a service originally defined in WSDL, using the WSDL to IDL mapping defined in this specification.

The second subcase (optional for conformance) is for a CORBA client accessing a WSDL service, which is itself a transated spec originally defined in IDL, which has incorporated a source indication in the translated WSDL file. This mechanism, to avoid round trip translation, is specified in the separate IDL to WSDL specification.

Implementation of the second sub case needs to be clarified, by the FTF including additional descriptive text, as an optional conformance point for WSDL/SOAP to CORBA Interworking.

see above

Clause 6.5 states the clause is preliminary.

Resolution proposed by Originator:

After FTF resolves all the complex type issues, delete the sentence “This section is preliminary”.

editorial

Description of Issue:

Clause 6.4.3 has a generic mapping of restricted XML types to wstring. It would provide more information to the receiver if there was a different IDL typedef of wstring for each restricted XML type in the list.

Resolution proposed by Originator:

FTF should provide a separate typedef of wstring for mapping each of the generic types listed in clause 6.4.3.

Close with addition of separate typdef for each generic type in a special IDL module

Description of Issue:

Clause 6.5 has no mapping for xml attributes of complex types. They are used a lot in WSDL document definitions.

Resolution proposed by Originator:

FTF should provide mapping for xml attributes of complexType. Originator suggests mapping each xml attribute as an additional elements within the IDL struct corresponding to the complex type.

Treat attributes as extra members, added to the mapped IDL struct for the complex type

Description of Issue:

Clause 6.5 has no mapping for elements of complex types with maxOccurs>1. This is used a lot in WSDL document definitions.

Resolution proposed by Originator:

FTF should provide mapping for elements in ComplexContent which have maxOccurs>1. Originator suggests mapping to an IDL sequence element within the struct corresponding to the complex type.

Add new subsection to cover mapping elements with cardinality

Description of Issue:

Clause 6.5 has no mapping for elements of complex types with minOccurs=0. This is used a lot in WSDL document definitions.

Resolution proposed by Originator:

FTF should provide mapping for elements with minOccurs=0 within a complex type. Originator suggests mapping to an IDL sequence element within the struct corresponding to the complex type.

see above

Description of Issue:

6.5 is missing subsection for mapping xsd:all, however it is mapped the same as xsd:sequence in the example section.

Resolution proposed by Originator:

FTF should add a new subsection to specify the mapping for ComplexContent “all”. The mapping should be the same as for sequence.

map all similar to sequence

Description of Issue:

Clause 5, resulting from the new Specification Template, needs to be completed.

Resolution proposed by Originator:

FTF needs to provide text for symbols and abbreviations clause.

Add appropriate abbreviations text

Description of Issue:

Clause 4, resulting from the new Specification Template, needs to be completed.

Resolution proposed by Originator:

FTF need to provide text for terminology clause.

Add a terminology clause

Clause 3, resulting from the new Specification Template, needs to be completed.

Resolution proposed by Originator:

FTF needs to provide complete set of references

FTF needs to provide complete set of references