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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

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


Subject: RE: [wsdm] WS-ResourceProperties and .NET implementations


Title: Message
Igor,
 
My approach would be to make minor changes to the WS-RP WSDL and schema to make it work as it appears to be intended by the specification. In order to do this we temporarily need to have our own copies of the WS-RP files. For .NET the WSDL tool used should be from the WSE 2.0 toolkit (wsewsdl) rather than the one shipped with the .NET Framework - there are several bug fixes in it. For the specific problems you discovered I propose the following solutions:
 
#1: I agree with you that the current WSDL does not reflect the intent of the specification as shown in the example SOAP messages. Your suggested change should be incorporated into the WSDL except that namespace="##other" should be added to the any element.
 
#2: I think the WSDL here is correct and any implementation complying to this WSDL should interoperate just fine. Clearly it is the intent of the spec to have a list of QNames as an argument to GetMultiple... So, rather than changing the operation here, I would suggest that for platforms that do not support the list construct in schema, that they code around it. This means that argument would be interpreted as a string by the code and split into a list internally. This will still interoperate on the message level with platforms that do support the list construct. I suggest no change here.
 
#3: This seems to be a bug in the .NET WSDL tool (including wsewsdl). Since we temporarily need our own copies of the WSDL and schema files, we can work around this problem by replacing the value of the schemaLocation attribute with just the file name - make it only WS-ResourceProperties.xsd. With this change it should work. I am not sure what the right answer is when WS-RP files have been fixed and have a final home. The same change is OK in final files as long as the WSDL and schema files are located in the same directory. The right answer is to get Microsoft to fix the tool.
 
Bryan
-----Original Message-----
From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
Sent: Wednesday, February 25, 2004 8:43 PM
To: wsdm@lists.oasis-open.org
Subject: [wsdm] WS-ResourceProperties and .NET implementations

I have spent some time trying to see if the subj. could be implemented and it provides to be quite a challenge. Here are my findings that I wanted to share with the group and see if anyone else tried it with a better outcome.

#1
I'm not sure that the following is right

[<xsd:element name="GetResourcePropertyResponse" type="xsd:anyType"/>]

This definition requires SOAP serializer to include xsi:type *of the element itself*. This definition contradicts what the specifications says. What the spec says it should be

[<GetResourcePropertyResponse><abc:property>value</abc:property></GetResourcePropertyResponse>]

According to the above element declaration, it will *always* be serialized as

[<GetResourcePropertyResponse xsi:type="whateverAbcPropertyType">value</GetResourcePropertyResponse>]

The response element should be declared as a container.

[
<xsd:element name="GetResourcePropertyResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:any minOccurs="0" maxOccurs="1" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
]

#2
The following does not appear to be interoperable at all.

[
<xsd:element name="GetMultipleResourcePropertiesRequest">
<xsd:simpleType>
<xsd:list itemType="xsd:QName" />
</xsd:simpleType>
</xsd:element>
]

The simple type list definition is merely ignored and looks like this [System.Xml.XmlQualifiedName GetMultipleResourcePropertiesRequest] in the code.

We can, of course, wait until it is fixed by Microsoft, but I don't think we can, and so WS-ResourceProperties must be fixed. Following is one possibility.

[
<xsd:element name="GetMultipleResourcePropertiesRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="qname" type="xsd:QName" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
]

#3
[
   <wsdl:types>
     <xsd:schema
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        targetNamespace=
  "http://www.ibm.com/xmlns/stdwip/web-services/WS-ResourceProperties">

       <xsd:include schemaLocation=
 "http://www-106.ibm.com/developerworks/webservices/library/ws-resource/WS-ResourceProperties.xsd"
       />
]

Tools think that two definitions of the same namespace exist. Both this schema and the included schema define the same namespace.

Inlining schema in the WSDL of WS-ResourceProperties helps resolve this. Another approach is to xsd:import and introduce dummy namespace in WSDL types section.

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



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