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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrf message

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


Subject: RE: [wsrf] WSRF WSDL problems with MS tooling


Glenn, that is right, I've had this one too long time ago when the specs
were originally published. <xs:include> does not work properly in MS
tools.

While there is no way to use the existing official wsdls, there is an
easy work around by fixing your local wsdls to either a) inline all the
schema decls or 2) import the schemas (instead of include) and change
the tns of the WSDL schema to something like <whatever it is now>/dummy.
Either way it does not affect actual interop of the message exchanges
and services that you may be exposing may render WSDL any way you like
as long as message exchanges are properly described. For the services
that you consume, my general suggestion is to transform WSDLs and cache
them locally. .NET would do it anyways, so just fix those local ones.


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


-----Original Message-----
From: Glenn Wasson [mailto:wasson@virginia.edu] 
Sent: Friday, October 29, 2004 2:35 PM
To: wsrf@lists.oasis-open.org
Subject: [wsrf] WSRF WSDL problems with MS tooling

This has actually been an issue for some time, and I should have raised
it formally before now.

The WSDL for WSRF-RP, WSRF-RL and WSRF-SG all use <xsd:include> which
the Microsoft tooling (wsdl.exe) does not handle properly. Although it
is legal WSDL, wsdl.exe cannot handle an included schema with the same
targetNamespace as the <xsd:schema> element it is being included into.

For example in the WSRF-RP WSDL:
    <wsdl:types>
      <xsd:schema
         xmlns:xsd="http://www.w3.org/2001/XMLSchema";
         targetNamespace=

 
"http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceProperties-1.2-
draft-01.xsd"
         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

        <xsd:include schemaLocation=

 
"http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceProperties-1.2-
draft-01.xsd"
        />


And in the WSRF-RP xsd:
 <xsd:schema
   xmlns:xsd="http://www.w3.org/2001/XMLSchema";
   xmlns:wsrp=

 
"http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceProperties-1.2-
draft-01.xsd"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   elementFormDefault="qualified" attributeFormDefault="unqualified"
   targetNamespace=

 
"http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceProperties-1.2-
draft-01.xsd"



The targetNamespace of the <xsd:schema> element in the WSDL matches the
targetNamespace of the <xsd:include>'d schema from the XSD.

However, wsdl.exe does correctly handle <xsd:import>. So, there are a
couple of questions:

1. Should we change the WSDL to allow processing by wsdl.exe?

2. If we do change the WSDL, how should we resolve the issue?

	I think the simplest change that would allow wsdl.exe to process
the WSDL would be to change all the <xsd:include>s to <xsd:import>s.
This would, however, necessitate changing the target namespace of the
imported schemas. If people want to suggest other potential fixes, I
will test those out as well.


Glenn

---
Glenn Wasson
wasson@virginia.edu
http://www.cs.virginia.edu/~gsw2c/






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