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:35:30 UTC