- From: Amelia A Lewis <alewis@tibco.com>
- Date: Wed, 30 Mar 2005 16:04:19 -0500
- To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Cc: www-ws-desc@w3.org
Hmm, again. On Wed, 30 Mar 2005 11:10:33 -0800 Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote: > The proposal as it stands says: > "All inline schemas that are contained in a WSDL document and any other > WSDL documents that it directly or indirectly imports or includes MUST > be used when resolving QName references to elements or types that belong > to namespaces that are imported via xs:import elements that have no > schemaLocation attribute." Well, all I can really say is that schema import doesn't work like this, and we claim to be doing more or less the same thing. > This implies that any element/type defined in namespace > http://example.com/type, when processing wsdl1, MUST be the one defined > in the wsdl2 embedded schema. Ugh. If we've done this in our attempts to define import and include, we've killed ourselves. If schema A imports schema B, and schema B imports schema C, what components of schema C are visible in schema A? a) all of them b) only the ones used by B c) none of them The correct answer is "c". This is surprising, to many people, but it is how schema import works. If embedded schemas are treated as inlined imports, then it follows that only the embedded schema itself is visible to its containing WSDL; none of its imports are. Similarly, the WSDL components defined in a WSDL import would be visible, but none of the schema components (whether imported or imported inline) would be. If WSDL is redefining the horizon of visibility, this is going to cause major issues with schema consistency. Amy! -- Amelia A. Lewis Senior Architect TIBCO/Extensibility, Inc. alewis@tibco.com
Received on Wednesday, 30 March 2005 21:03:13 UTC