W3C home > Mailing lists > Public > public-ws-desc-comments@w3.org > December 2004

wsdl:import semantics is different from xs:import

From: Asir Vedamuthu <asirv@webmethods.com>
Date: Wed, 15 Dec 2004 07:37:37 -0500
Message-ID: <5B10E50E14A4594EB1B5566B69AD9407068E692D@maileast>
To: public-ws-desc-comments@w3.org

[On behalf of the XML Schema WG]

WSDL Part 1 says: 

"The WSDL import element information item, like the include element
information item (see 4.1 Including Descriptions) also allows for the
separation of the different components of a WSDL description into
independent descriptions, but in this case with different target namespaces,
which can be imported as needed. This technique helps writing clearer WSDL
descriptions by separating the definitions according to their level of
abstraction, and maximizes reusability.

The WSDL import element information item is modeled after the XML Schema
import element information item (see [XML Schema: Structures], section 4.2.3
"References to schema components across namespaces"). Specifically, it can
be used to import components from WSDL descriptions that do not share a
target namespace with the importing document. Components in directly
imported descriptions are part of the component model of the importing
description. Directly imported means that component importation is not
transitive; components imported by one of the imported documents are not
available to the original importing document unless the are imported
directly by that document. The imported components can be referenced by
QName." 

http://www.w3.org/TR/2004/WD-wsdl20-20040803/#imports

Some background on XML Schema Import
------------------------------------

As with include, the comparison here seems to be based on some
misconceptions about how XML Schema works. Let us briefly clarify the
behavior of XML Schema xsd:import.

First of all, xsd:include and xsd:import are different in XML schema, and
not just because include works within a single namespace. The primary
purpose of xsd:include is to bring in new components from another schema
document; the primary purpose of xsd:import is to allow references to a
foreign namespace from within a schema document. This function perhaps
become clearer when one notices that the only mandatory information on an
import is in the following form:

<import namespace="nsUri" />

Note that there is no mandatory schemaLocation hint; whether the occurrence
of this import causes "importation" of new components for namespace nsUri is
at the discretion of the processor. What is mandatory is that an import
appear for any referenced namespace. So, we have:

Legal:

<schema xmlns:ns="nsUri">
 <import namespace="nsUri" />
 <element name="e" type="ns:t"/>
</schema>

Not Legal:

<schema xmlns:ns="nsUri">
 <!--missing import -->
 <element name="e" type="ns:t"/>
</schema>

Where might the definition for type ns:t come from in the above example? A
schema document containing the definition could have been named as an
argument to the processor, could have been identified in an
xsi:schemaLocation hint in an instance, or might have been imported as a
side effect of processing some other schema document. The definition might
also have been built into the processor (e.g. an HTML editor with built in
knowledge of HTML validation.)

In general, with the exception of <xsd:include> and <xsd:redefine>, XML
processors can use most any policy for locating schema documents and
components. Of course, there is a very commonly used strategy, which is to
honor schemaLocation hints on an import:

<schema xmlns:ns="nsUri">
 <import namespace="nsUri" 
     schemaLocation="http://example.org/nsURischema.xsd/>
 <element name="e" type="ns:t"/>
</schema>

Because many processors honor such hints, it's a common misconception that
components are imported by import statements. That appears to be true of
WSDL, but not of Schema.

Also, as already noted in our comment on include, the visibility of global
components in XML schema is pervasive. The ability to reference a global
component does not depend on the schema location document in which the
reference occurs. Insofar as components are brought in as a result of nested
schemaLocation hints, the visibility is indeed (to use your term)
transitive. This appears to be another difference between the WSDL and
Schema designs.

Suggested change
----------------

As with include, we think there would be some "least astonishment" value for
users if WSDL were to follow Schema's lead, but we certainly don't insist
that you do. As with include, we would like to understand the reasons for
any differences that you decide to retain. We do feel it's appropriate to
formally request that any comparisons drawn to the schema design be
accurate, so we request that you either remove or correct the text that
suggests that WSDL and Schema import behave similarly. As currently
specified, it appears that they are different with respect both to the role
of import in bringing components into a WSDL or Schema definition, and also
in the degree to which such components are globally visible.

Regards,
Asir S Vedamuthu
asirv at webmethods dot com
http://www.webmethods.com/ 
Received on Wednesday, 15 December 2004 12:38:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:31 GMT