RE: Problem with Service References: elementFormDefault="qualified" prevents restriction

Thank you for your comment, which we tracked as LC117 [1].  The WG
resolved to remove the Service Reference section in the core, to define
wsdlx:interface and wsdlx:binding extensions in the Core, to be used as
schema annotations, illustrate the use of these attributes in the Primer
with URIs, to make @name required on Service and Endpoint types in the
schema, and to coordinate with WS-A in illustrating support on
wsa:EndpointReferences.  If this resolution is unacceptable, please let
us know within two weeks.





From: [] On
Behalf Of Arthur Ryman
Sent: Monday, March 28, 2005 1:42 PM
Subject: Problem with Service References: elementFormDefault="qualified"
prevents restriction


In the process of writing the Primer section on Service References, I
have found a problem in the solution we adopted. The context of this
topic is that some services may reference to other services, and we were
defining a way that WSDL could be used to describe the interface and
binding of the service that was being refered to. 

Recall that the we decided to go with Roberto's counter-proposal [1]
which was based on the idea of using XSD to restrict wsdl:ServiceType
and wsdl:Endpoint to have fixed values for @interface and @binding, and
to transmit service references using the restricted wsd:ServiceType. 

If you just want to say that a message contains a reference to another
service and you don't want to contrains the interface or binding, then
you directly re-use the wsdl:ServiceType in the message. 

If you want to describe the interface of the service, then you create a
new type that restricts the value of the @interface attribute to have a
fixed value which is the QName of the interface. This works, e.g. 

If you also want to describe the binding of the service, then you create
a new type that restricts the value of the @binding attribute of
wsdl:EndpointType. You can do that, but there is no way you can actually
use this type to restrict the <wsdl:endpoint> element. Here is a sample.

<?xml version="1.0" encoding="UTF-8"?> 
<schema xmlns="" 

        <import namespace="" 
                schemaLocation="wsdl20-1.xsd" /> 

        <complexType name="ReservationDetailsEndpointType"> 
                        <restriction base="wsdl:EndpointType"> 
                                <attribute name="binding" type="QName"
fixed="wdetails:reservationDetailsSOAPBinding" /> 

        <complexType name="ReservationDetailsServiceType"> 
                        <restriction base="wsdl:ServiceType"> 
                                        <element name="endpoint" 
type="tns:ReservationDetailsEndpointType" /> 
                                <attribute name="interface" type="QName"
fixed="wdetails:reservationDetailsInterface" /> 

The problem is that within the <restriction> of wsdl:ServiceType, the
<element name="endpoint" ...> refers the QName tns:endpoint, not
wsdl:endpoint because we use elementFormDefault="qualified". This is
actually a valid restriction since the content model of wsdl:ServiceType
allows elements from other namespaces. However, this does not restrict
the wsdl:endpoint element to have the fixed binding value. FYI, here is
a chunk of a valid instance document according to this restricted
service type. 

                        <details:endpoint name="SOAP" 

There is a fix however. The reason that we were able to restrict the
attribute values is that they are unqualified. Therefore, if we changed
our WSDL schema to use elementFormDefault="unqualified", and we ensured
that <endpoint> was a local element, then we could restrict it. However,
for consistency, we should probably also make the other nested elements
unqualified, i.e. just keep the top-level elements (<interface>,
<binding>, <service>, etc.) qualified. We can still have named complex
types for all the elements though. 

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text:

Received on Thursday, 9 June 2005 21:04:44 UTC