[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/
>
>
>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]