- From: Asir Vedamuthu <asirv@webmethods.com>
- Date: Wed, 15 Dec 2004 07:37:37 -0500
- 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 UTC