Re: [Issues] WSDL and INLINE Schema Definitions

I agree this approach would be consistent with XSD usage.
However, usability would be a bit shot ..

Would this effectively restrict <wsdl:import> to only import
WSDL documents?

Bye,

Sanjiva.

----- Original Message -----
From: "Martin Gudgin" <mgudgin@microsoft.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>; <asirv@webmethods.com>;
"Web Service Description" <www-ws-desc@w3.org>
Cc: <prasad.yendluri@webmethods.com>
Sent: Monday, September 09, 2002 4:45 AM
Subject: RE: [Issues] WSDL and INLINE Schema Definitions


> 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 Monday, 9 September 2002 07:05:38 UTC