W3C home > Mailing lists > Public > www-ws-desc@w3.org > September 2002

[Issues] WSDL and INLINE Schema Definitions

From: Asir S Vedamuthu <asirv@webmethods.com>
Date: Fri, 6 Sep 2002 13:10:15 -0400
To: "Web Service Description" <www-ws-desc@w3.org>
Cc: "Martin Gudgin" <mgudgin@microsoft.com>, <prasad.yendluri@webmethods.com>
Message-ID: <OKEBJFDOCNPMPLOONLOIEEJLCOAA.asirv@webmethods.com>

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 Friday, 6 September 2002 13:09:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:21 GMT