[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
5.1.2 WSDL and Schema Import
Some examples in WSDL 1.1 incorrectly show the WSDL import statement
being used to import XML Schema definitions. The Profile clarifies use
of the import mechanisms to keep them consistent and confined to their
respective domains. Imported schema documents are also constrained by
XML version and encoding requirements consistent to those of the
importing WSDL documents.
R2001 A DESCRIPTION MUST only use the WSDL "import"
statement to import another WSDL description.
R2002 To import XML Schema Definitions, a DESCRIPTION MUST
use the XML Schema "import" statement.
R2003 A DESCRIPTION MUST use the XML Schema "import"
statement only within the xsd:schema element of the types
section.
I guess it's a question of interpretation whether the first word "import"
in R2002 encompasses xsd:include, or whether R2002 just means "don't use
wsdl:import to do this" or whether it also refers to xsd:include.
However, as Steve has pointed out, we could avoid using xsd:include by
putting all the schema material in a single file (per spec).
Peter Niblett
Glenn Wasson
<wasson@virginia.
edu> To
wsrf@lists.oasis-open.org
02/11/2004 02:48 cc
Subject
RE: [wsrf] WSRF WSDL problems with
MS tooling (fwd)
Igor,
So this is what we've been doing for a while now in our
implementation (inlining the schemas), but I don't think it is a great
solution. I'm not sure what you mean by ".NET would do it anyway", but
wsdl.exe doesn't have any mechanism for this type of caching. Currently,
we modify other implementation's service's WSDL to point to our version of
the specs WSDL. Seems non-ideal. Since it looks like the WS-I basic
profile says to use the import statement to import additional schema
documents, I think we should rework the specs as Steve suggests.
Glenn
---
Glenn Wasson
wasson@virginia.edu
http://www.cs.virginia.edu/~gsw2c/
On Mon, 1 Nov 2004, Sedukhin, Igor S wrote:
> 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/
>
>
>
>
>
>
>
--=_alternative 0058A42D85256F40_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Ian:</font>
<br><font size=2 face="sans-serif">Yes, the location URLs was the major
motivator behind the choice of namespace URIs.</font>
<br>
<br><font size=2 face="sans-serif">I would like to understand other folks'
opinion.</font>
<br><font size=2 face="sans-serif">"The current namespace URI approach,
with separate namespaces for the WSDL and XSD files is a good approach".</font>
<br>
<br><font size=2 face="sans-serif">Please weigh in with a yea or ney and
perhaps a few words on why you voted in this way.</font>
<br>
<br><font size=2 face="sans-serif">Heck, this is an election day in the
US, I am in a voting kinda mood!</font>
<br>
<br><font size=2 face="sans-serif">sgg</font>
<br><font size=2 face="sans-serif"><br>
++++++++<br>
Steve Graham<br>
(919)254-0615 (T/L 444)<br>
STSM, On Demand Architecture<br>
Member, IBM Academy of Technology<br>
<Soli Deo Gloria/><br>
++++++++<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Springer, Ian P."
<ian.springer@hp.com></b> </font>
<p><font size=1 face="sans-serif">11/02/2004 10:45 AM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">Steve Graham/Raleigh/IBM@IBMUS</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif"><wsrf@lists.oasis-open.org></font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">RE: [wsrf] WSRF WSDL problems
with MS tooling (fwd)</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>The only benefit I saw of having two namespaces was
that the namespaces could be the location URLs of the xsd and the wsdl.
The big con is that it's much more error-prone from a developer perspective.<br>
<br>
________________________________<br>
<br>
From: Steve Graham [mailto:sggraham@us.ibm.com]<br>
Sent: Tue 11/2/2004 10:32 AM<br>
To: Springer, Ian P.<br>
Cc: wsrf@lists.oasis-open.org<br>
Subject: RE: [wsrf] WSRF WSDL problems with MS tooling (fwd)<br>
<br>
<br>
<br>
well, we have tried out having separate namespace for wsdl, and I am not
sure there is much benefit. One fewer namespace uri is probably a
good thing. <br>
<br>
++++++++<br>
Steve Graham<br>
(919)254-0615 (T/L 444)<br>
STSM, On Demand Architecture<br>
Member, IBM Academy of Technology<br>
<Soli Deo Gloria/><br>
++++++++<br>
<br>
<br>
<br>
<br>
"Springer, Ian P." <ian.springer@hp.com> <br>
<br>
11/02/2004 09:54 AM <br>
<br>
To<br>
<wsrf@lists.oasis-open.org> <br>
cc<br>
Subject<br>
RE: [wsrf] WSRF WSDL problems with MS tooling (fwd)
<br>
<br>
<br>
<br>
<br>
<br>
<br>
| However, as Steve has pointed out, we could avoid using xsd:include by<br>
| putting all the schema material in a single file (per spec).<br>
<br>
You wouldn't necessarily have to put all the schema material in the xsd
file. The wsdl types/schema could use the wsdl namespace (or any namespace
other than the xsd namesapce) as its targetNamespace and then xsd:import
the xsd file into the xsd namespace. This would allow you to continue following
the current convention of putting all Request/Response/Fault types in the
wsdl and all "data" types in the xsd, with the difference being
that the Request/Response/Fault types would live in the wsdl namespace.<br>
<br>
Ian<br>
<br>
<br>
________________________________<br>
<br>
From: Peter Niblett [mailto:peter_niblett@uk.ibm.com]<br>
Sent: Tue 11/2/2004 6:56 AM<br>
To: wsrf@lists.oasis-open.org<br>
Subject: RE: [wsrf] WSRF WSDL problems with MS tooling (fwd)<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Glenn<br>
<br>
I've had a quick read of the WS-I basic profile, and I can't see anywhere<br>
where it says you should not use include. It seems to be more concerned<br>
that you should not use wsdl:import to import schema definitions.<br>
<br>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]