Re: [wsrf] WSRF81: Investigations and proposed resolution

[Steve Graham <sggraham@us.ibm.com>]

good summary Tim, thanks.

>c) Is simplest.  I like this option best,
even in spite of this rule in
>WSDL 2.0 (found by IanR) " 3.1.2.1 targetNamespace attribute information
>item
>The targetNamespace attribute information item defines the namespace
of the
>element declarations and type definitions embedded in its [owner] xs:schema
>element information item. WSDL modifies the XML Schema definition of
the
>xs:schema element information item to make this attribute information
item
>required."
>Let's cross that bridge when we reach it.
+1

FWIW, we could also address the concern
Ian raises by using the namespace uri of the wsdl file as the 
targetNamespace of the schema defined
in the WSDL types section (essentially combining proposals a) and c).
So for example, in wsrf-rp's WSDL:

<wsdl:definitions name="WS-ResourceProperties"
  xmlns=...
>
  
<!-- ===================== Types Definitions
====================== -->
   <wsdl:types>
     <xsd:schema 
        targetNamespace=
  "http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceProperties-1.2-draft-05.wsdl"
        elementFormDefault="qualified"

        attributeFormDefault="unqualified">

       <xsd:import

          namespace=
       "http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceProperties-1.2-draft-05.xsd"
          schemaLocation=
       "http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceProperties-1.2-draft-05.xsd"
       /> 
       
       <xsd:import

          namespace=
       "http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-BaseFaults-1.2-draft-03.xsd"
          schemaLocation=
       "http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-BaseFaults-1.2-draft-03.xsd"

       />
        </xsd:schema>
    </wsdl:types>
...
</wsdl:definitions>

As a passing note.  I notice that
the WSDL for WS-Eventing [1] uses xs:include in its wsdl:types/xsd:schema.
 I guess
MSFT didn't encounter the same bug as
Glenn is encountering.

sgg
[1]ftp://www6.software.ibm.com/software/developer/library/ws-eventing/WS-Eventing.pdf
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++

Tim Banks <tim_banks@uk.ibm.com>

12/08/2004 08:16 AM

To	wsrf@lists.oasis-open.org
cc
Subject	[wsrf] WSRF81: Investigations and  proposed resolution

Background
------------------

Issue 81 says:

  "Some tooling does not correctly handle xsd:include."

The second sentence "WS-I compliance requires that xsd:include not
be used.
" was countered by Peter Niblett in
http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200411/msg00015.html



The email by Glenn here
http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200410/msg00113.html
  reported a bug in MS tools, but there are also issues in processing
of
<xsd:include> by other tools based on WSDL2Java, namely different
ways of
handling multiple <xsd:include> elements for the same inclusion such
as:

<xsd:schema>
  <xsd:include schemaLocation="L">
  <xsd:include schemaLocation="L">
<...

Some tools report as errors the duplicate definitions brought in by the
second inclusion.  Some don't.

Reporting this construction as an error seems to be a mistake according
to
the following note in section 4.2.1 of http://www.w3.org/TR/xmlschema-1:

"Note: The above is carefully worded so that multiple <include>ing
of the
same schema document will not constitute a violation of clause 2 of Schema
Properties Correct (§3.15.6), but applications are allowed, indeed
encouraged, to avoid <include>ing the same schema document more than
once
to forestall the necessity of establishing identity component by
component."

Suppose WS resource 'A'  is constructed from an xsd file which defines
complex types and resource property elements, and a wsdl file with an
embedded schema.  The embedded schema includes the xsd (via <xsd:include>),
defines message body elements and assembles the Resource Properties
document.   The specs are constucted like this, and any WS Resource
could
be constructed in the same way, which seems intuitive, to me.

If a WS Resource 'B' wants to extend a WS Resource  'A'  which
is
constructed in this way,  'B' must:

1.  <wsdl:import>  'A's wsdl to get the message definitions
2. Copy/paste the operations (which refer to the message defs) into a new
portType
3. <xsd:import> 'A's  xsd into the  wsdl:types/xsd:schema
to get the
Resource Property element definitions
4.  Construct a Resource Properties document in wsdl:types/xsd:schema
and
refer to it from the new portType.

Now, some tools report 'B's wsdl as valid, but some report it as invalid
because of duplicate definitions included indirectly by step 1. and
included directly by step 3.  Thanks to Ian Robinson for this discovery.

So, since ServiceGroup.wsdl  extends ResourceProperties.wsdl, it is
'invalid', according to some tools. And since ServiceGroup uses the
<include> technique, ServiceGroupRegistration is 'invalid' too, since
it
extends ServiceGroup.


Proposal
-------------

The proposal by Glenn was to use to change the targetnamespace of
wsdl:types/xsd:schema to allow the use of xsd:import instead of xsd:include
This avoids the MS bug.  Luckily, this also avoids the errors reported
by
tools based on WSDL2Java since it is tolerant of multiple <xsd:import>
elements for the same namespace.  A note in section 4.2.2 of
http://www.w3.org/TR/xmlschema-1 advises that this tolerance is required.

Apart for waiting for tools changes, which leaves WSRF hostage to fortune,
there are three ways to solve the problem:

a) Use the .wsdl targetnamespace in wsdl:types/xsd:schema
b) Introduce a new targetnamespace
c) SteveG's suggestion: remove all schema components to the xsd file and
use no targetnamespace on the wsdl:types/xsd:schema.  BaseFaults already
uses this technique.


a) is counter to what seems to be the established constuction of wsdl which
is described in the WSDL 2  primer (see
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.html)
Here the wsdl:types/xsd:schema uses an '.xsd.' targetnamespace.

b) Seems awkward,

c) Is simplest.  I like this option best, even in spite of this rule
in
WSDL 2.0 (found by IanR) " 3.1.2.1 targetNamespace attribute information
item
The targetNamespace attribute information item defines the namespace of
the
element declarations and type definitions embedded in its [owner] xs:schema
element information item. WSDL modifies the XML Schema definition of the
xs:schema element information item to make this attribute information item
required."
Let's cross that bridge when we reach it.


Regards, Tim Banks
IBM TP Architecture & Technology. Hursley, UK.
Phone: External +44 1962 815639, Internal 245639