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


I have added this issue to the WSRF issues list which I will publish
again before our next call.

Bryan 

-----Original Message-----
From: Ian Robinson [mailto:ian_robinson@uk.ibm.com] 
Sent: Monday, November 01, 2004 5:28 AM
To: Steve Graham; Murray, Bryan P.
Cc: Glenn Wasson; wsrf@lists.oasis-open.org
Subject: Re: [wsrf] WSRF WSDL problems with MS tooling





If Bryan adds this as a new issue, raised by Glenn, we can discuss on
the next call whether we think this is something we should address in
the WSRF schema & wsdl.

Regards,
Ian Robinson
STSM, WebSphere Messaging and Transactions Architect IBM Hursley Lab, UK
ian_robinson@uk.ibm.com


 

             Steve Graham

             <sggraham@us.ibm.

             com>
To 
                                       Glenn Wasson
<wasson@virginia.edu>  
             01/11/2004 13:01
cc 
                                       wsrf@lists.oasis-open.org

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

 

 

 

 

 

 






Glenn:
Have you reported this bug to MSFT and ascertained their date for fixing
this?

Although I am terribly allergic to changing legal WSDL to work around
defects in other vendor's tools, this would not be the first time (same
vendor's tools).

Actually, I have been mulling over a change for some time, but for
different reasons.  It seems to be quite "fashionable" to isolate ALL of
the XSD into a single .xsd file (per specification, of course), and
relegate the WSDL types element to simply import/include that file.  It
simplifies the WSDL and concentrates the XSD into a single space.  I
suspect that having all of the XSD for a given spec in one xsd file will
assist search etc.

So, how shall we work the process?  Shall we request Glenn open a formal
issue request against all the specs, discuss possible alternatives and
then as a TC agree upon the resolution to the issue?

sgg

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++


 

 Glenn Wasson <wasson@virginia.edu>

 

 

 10/29/2004 02:35 PM
To 
                                               wsrf@lists.oasis-open.org

 
cc 
 

 
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-d
raft-01.xsd
"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified">

       <xsd:include schemaLocation=

"
http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceProperties-1.2-d
raft-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-d
raft-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-d
raft-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]