RE: wsdl:import semantics is different from xs:import

Thank you for your comment - we tracked this as a Last Call comment LC96
[1].  The Working Group agreed to fix wsdl:import to act consistently
with xsd:import.  We'd appreciate your further review of the revised
text which can be found at [2].

If we don't hear otherwise within two weeks, we will assume this
satisfies your concern.

[1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC96
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html#impo
rts

> -----Original Message-----
> From: public-ws-desc-comments-request@w3.org [mailto:public-ws-desc-
> comments-request@w3.org] On Behalf Of Asir Vedamuthu
> Sent: Wednesday, December 15, 2004 4:38 AM
> To: public-ws-desc-comments@w3.org
> Subject: wsdl:import semantics is different from xs:import
> 
> 
> [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 Saturday, 28 May 2005 22:26:27 UTC