- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Sun, 8 Sep 2002 15:45:05 -0700
- To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, <asirv@webmethods.com>, "Web Service Description" <www-ws-desc@w3.org>
- Cc: <prasad.yendluri@webmethods.com>
We should add these to the issues list. I think I'd also like to suggest that importing SCHEMAS using wsdl:import should be disallowed. If someone wants to import a schema then they should do <wsdl:types> <xsd:schema> <xsd:import namespace='...' /> </xsd:schema> </wsdl:types> Gudge > -----Original Message----- > From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] > Sent: 07 September 2002 07:25 > To: asirv@webmethods.com; Web Service Description > Cc: Martin Gudgin; prasad.yendluri@webmethods.com > Subject: Re: [Issues] WSDL and INLINE Schema Definitions > > > +1 to all the resolutions proposed by Gudge below. > > Sanjiva. > > ----- Original Message ----- > From: "Asir S Vedamuthu" <asirv@webmethods.com> > To: "Web Service Description" <www-ws-desc@w3.org> > Cc: "Martin Gudgin" <mgudgin@microsoft.com>; > <prasad.yendluri@webmethods.com> > Sent: Friday, September 06, 2002 11:10 PM > Subject: [Issues] WSDL and INLINE Schema Definitions > > > > > > With permissions from Martin (thank you !!), I am posting > this thread > > to > the > > WSDesc WG. Please review and address them as appropriate. > > > > Regards, > > > > Asir S Vedamuthu > > > > webMethods, Inc. > > 703-460-2513 or asirv@webmethods.com http://www.webmethods.com/ > > > > > > -----Original Message----- > > From: Martin Gudgin [mailto:mgudgin@microsoft.com] > > Sent: Friday, September 06, 2002 5:20 AM > > To: asirv@webmethods.com > > Subject: RE: Challenges raised by INLINE Schema Definitions > > > > > > [inline] > > > > > -----Original Message----- > > > From: Asir S Vedamuthu [mailto:asirv@webmethods.com] > > > Sent: 05 September 2002 15:35 > > > To: Martin Gudgin > > > Subject: FW: Challenges raised by INLINE Schema Definitions > > > > > > > > > Martin, > > > > > > What are your thoughts on this? Thank you. > > > > > > Asir > > > > > > -----Original Message----- > > > From: w3c-xml-schema-ig-request@w3.org > > > [mailto:w3c-xml-schema-ig-request@w3.org]On Behalf Of > Asir S Vedamuthu > > > Sent: Wednesday, August 21, 2002 11:17 AM > > > To: 'w3c-xml-schema-ig' > > > Subject: Challenges raised by INLINE Schema Definitions > > > > > > > > > > > > What is an INLINE Schema Definition? > > > > > > It is one or more schema elements; is not a root of the element > > > tree; embedded within an XML document. Example, a schema element > > > as a child of <types> element in a web service description. > > > > > > INLINE schema definitions are very popular and raises many > > > challenges. Based on the existing usage patterns, this e-mail > > > describes three challenges faced by schema processors. This is not > > > an exhaustive list. There are many more challenges along these > > > lines .. > > > > > > I request the schema WG and IG members to discuss these issues and > > > issue erratta, publish a note on inline schema definitions, OR > > > address these in XML Schema 1.1 version. > > > > > > > > > [1] What is the relationship among multiple INLINE schema > definitions? > > > > > > Current usage pattern: inline multiple schema definitions as > > > children of <types> element in a web service description. There > > > are references to schema components across schema definitions > > > without using <xsd:include> or <xsd:import> > statements. > > > > > > Example is, > > > > > > <wsd:types xmlns:A="http://www.example.com/A" > > > xmlns:B="http://www.example.com/B"> > > > > > > <xsd:schema targetNamespace="http://www.example.com/A"> > > > <xsd:element name="a" type="xsd:string"/> > > > .. > > > </xsd:schema> > > > > > > <xsd:schema targetNamespace="http://www.example.com/B"> > > > <xsd:element name="b" type="xsd:int"/> > > > .. > > > </xsd:schema> > > > > > > <xsd:schema targetNamespace="http://www.example.com/C"> > > > <xsd:element name="c"> > > > <xsd:complexType> > > > <xsd:sequence> > > > <xsd:element ref="A:a"/> > > > <xsd:element ref="B:b"/> > > > </xsd:sequence> > > > </xsd:complexType> > > > </xsd:element> > > > </xsd:schema> > > > > > > </wsd:types> > > > > > > What is the relationship? Is this legal? If so, what are the > > > processing rules? > > > > No it's not legal, because there is no import statement in > 'C'. However, > > the following WOULD be legal > > > > <wsd:types xmlns:A="http://www.example.com/A" > > xmlns:B="http://www.example.com/B"> > > > > <xsd:schema targetNamespace="http://www.example.com/A"> > > <xsd:element name="a" type="xsd:string"/> > > .. > > </xsd:schema> > > > > <xsd:schema targetNamespace="http://www.example.com/B"> > > <xsd:element name="b" type="xsd:int"/> > > .. > > </xsd:schema> > > > > <xsd:schema targetNamespace="http://www.example.com/C"> > > <xsd:import namespace='http://www.example.com/A' /> > > <xsd:import namespace='http://www.example.com/B' /> > > <xsd:element name="c"> > > <xsd:complexType> > > <xsd:sequence> > > <xsd:element ref="A:a"/> > > <xsd:element ref="B:b"/> > > </xsd:sequence> > > </xsd:complexType> > > </xsd:element> > > </xsd:schema> > > > > </wsd:types> > > > > > > > > > > > > > > > [2] AD HOC Built-in Types and Declarations > > > > > > Per XML Schema 1.0, there are a few built-in types: 'anyType' and > > > 'anySimpleType' from Part 1 and built-in simple types > from Part 2. > > > > > > Current usage pattern: certain type definitions and element / > > > attribute declarations that are germane to web service domain are > > > implicitly treated as built-in types and decls. Here is an > > > example, > > > > > > Example 3, WSDL Version 1.2: Bindings > > > http://www.w3.org/TR/2002/WD-wsdl12-bindings-20020709/#_soap-e > > > > > > <types> > > > <schema targetNamespace="http://example.com/stockquote/schema" > > > xmlns="http://www.w3.org/2000/10/XMLSchema"> > > > .. > > > <complexType name="ArrayOfFloat"> > > > <complexContent> > > > <restriction base="soapenc:Array"> > > > <attribute ref="soapenc:arrayType" > > > wsdl:arrayType="xsd:float[]"/> > > > </restriction> > > > </complexContent> > > > </complexType> > > > </schema> > > > </types> > > > > This is illegal too. There should be a > > > > <xsd:import namespace='http://schemas.xmlsoap.org/soap/encoding/' /> > > > > > > > > In this example, complex type soapenc:Array and attribute decl > > > soapenc:arrayType are considered to be built-ins. I believe that > > > this sample schema definition is invalid per XML Schema 1.0 spec. > > > Because, there aren't any import statements for the soapenc > > > namespace, http://schemas.xmlsoap.org/soap/encoding/. However, > > > this usage pattern demonstrates a need for extensible built-ins. > > > > I disagree, I think people should put the import statements into the > > schemas > > > > > > > > Today, this usage pattern is widely used and enforced by ad hoc > > > groups. > > > > WSDL 1.2 could ( and should ) fix this. > > > > > > > > > > > [3] Mandatory targetNamespace > > > > > > Per XML Schema 1.0, targetNamespace is optional. If absent, then > > > this schema definition defines and declares components that are > > > not considered to be in any namespace. > > > > > > Current usage pattern: targetNamespace is mandatory for inline > > > schema definitions within a web service description. > > > > What makes you think this? Given that all that appears in a > 'wsdl:types' > > element are <xsd:schema> elements, I don't see how anyone > can mandate > > targetNamespace without changing the schema spec. Is this a > tools issue? > > > > > > > > This takes away a huge functionality. I do know that implementers > > > have gone to lengths to implement this restriction. Let me > > > describe our experience. There are several webMethods users that > > > depend on ABSENT targetNamespace. To overcome this restriction and > > > support these users, we have introduced a special namespace URI in > > > markup that represents absent [namespace name] in XML > > > Information Sets - http://www.webMethods.com/noNamespace/ and > > > this is the targetNamespace :-( Here is a sample, > > > > > > <xsd:schema > targetNamespace="http://www.webMethods.com/noNamespace/" > > > xmlns="http://www.webMethods.com/noNamespace/"> > > > > > > <xsd:complexType name="purchaseOrder"> > > > <xsd:sequence> > > > <xsd:element name="shipTo" .. > > > .. > > > </xsd:sequence> > > > </xsd:complexType> > > > > > > <xsd:simpleType name="SKU"> > > > <xsd:restriction base="xsd:string"> > > > <xsd:pattern value="\d{3}-[A-Z]{2}"/> > > > </xsd:restriction> > > > </xsd:simpleType> > > > </xsd:schema> > > > > > > I believe that making targetNamespace mandatory is a huge loss of > > > functionality. > > > > I'm not sure it's huge, but it is certainly a loss! > > > > It is not clear to me why these are issues for the schema > WG/IG. Surely > > these are issues for the WSDesc WG, no? > > > > Gudge > >
Received on Sunday, 8 September 2002 20:25:00 UTC