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
- From: Steve Graham <sggraham@us.ibm.com>
- To: Glenn Wasson <wasson@virginia.edu>
- Date: Mon, 1 Nov 2004 08:01:41 -0500
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-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]