- From: Amelia A. Lewis <alewis@tibco.com>
- Date: Mon, 20 Oct 2003 13:41:43 -0400
- To: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Cc: www-ws-desc@w3.org
On Mon, 20 Oct 2003 23:26:47 +0600 Sanjiva Weerawarana <sanjiva@watson.ibm.com> wrote: > Obviously I didn't understand it then and I don't understand it now. > Why do we say that imported components are not available to WSDL? In > general, why do we go saying things about other people's specs?? We don't. Schema says this. We follow schema, pretty much, in defining visibility of our imports. An import can only be seen by its importing container; that importing container cannot "export" it. The importing container can only "export" the bits that it defines for itself. The rule of thumb is that there's a one-level horizon for imports. > Also, isn't the replacement really > <xs:schema><xs:include .../></xs:schema> Ah, this is different. An included schema is different, so that would work, and would be visible. So, sure, we could disallow xs:import as the immediate child of wsdl:types, and instead require that xs:schema contain an xs:include in order to incorporate an external schema definition. Rather more verbose, but perfectly plausible. There are some potential problems, in that xs:include does not have a namespace attribute; it is almost solely identifiable by its schemaLocation attribute, which may cause problems for folks using catalog-enabled systems. The targetNamespace issues for inclusions are also perhaps a little more tricky than we would really want to encourage people to have to mess with as a general thing. Overall, allowing xs:import as an immediate child of wsdl:types seems an awfully reasonable solution, as it is far easier to understand what the intended semantic is supposed to be, and it is also easier to get the syntax correct. Amy! -- Amelia A. Lewis Architect, TIBCO/Extensibility, Inc. alewis@tibco.com
Received on Monday, 20 October 2003 13:41:43 UTC