- From: Arthur Ryman <ryman@ca.ibm.com>
- Date: Mon, 18 Apr 2005 12:17:27 -0400
- To: David Booth <dbooth@w3.org>
- Cc: Martin Gudgin <mgudgin@microsoft.com>, www-ws-desc@w3.org, www-ws-desc-request@w3.org
- Message-ID: <OFE3C3C2BD.10B9E753-ON85256FE7.0057BD55-85256FE7.00597B5D@ca.ibm.com>
David, I don't think this works in general. The reason is that documents refer to each other so there really isn't a component model for each document.. You could have a document that didn't refer to any other document, and that would have a component model. That is a "leaf" node. Document can actually have circular references to eachother. The spec permits this. The component model therefore must include all the components in order to satisfy the intercomponent references. My reading of the spec is that all components belong to a single instance of the component model. The instance is defined by a root document and the set of documents it references. There are two possible ways we could improve the clarity of the spec: Option 1. Rename the Description Component to the Component Model This actually eliminates the Description component altogether and replaces it with an object called the Component Model. The spec talks a lot about the component model, but never actually defines it. We can make it clear that the component model contains all the components from all the documents processed. Option 2. Define the Component Model to be a set of Description Components, and restrict each Description component to only contain the components defined in it This makes the mapping between Description components and documents clearer. It introduces the technical subtlety of what to do about duplicated components. We currently allow duplicate components to come from different documents as long as the components are equivalent. To resolve component references, we need to pick a particular component among the set of equivant components (or formally introduce the notion of equivalence class and make component references resolve to those). Arthur Ryman, Rational Desktop Tools Development phone: +1-905-413-3077, TL 969-3077 assistant: +1-905-413-2411, TL 969-2411 fax: +1-905-413-4920, TL 969-4920 mobile: +1-416-939-5063, text: 4169395063@fido.ca intranet: http://labweb.torolab.ibm.com/DRY6/ David Booth <dbooth@w3.org> Sent by: www-ws-desc-request@w3.org 04/16/2005 12:02 PM To Martin Gudgin <mgudgin@microsoft.com> cc Arthur Ryman/Toronto/IBM@IBMCA, www-ws-desc@w3.org Subject RE: Contradictions regarding transitivity of wsdl:import On Fri, 2005-04-15 at 20:31, Martin Gudgin wrote: > > > -----Original Message----- > > From: David Booth [mailto:dbooth@w3.org] > > . . . > > I think it would be considerably clearer if the component model for a > > "WSDL 2.0 document"*** (see below) would consist of all and > > *only* those > > components that are supposed to be visible to that WSDL 2.0 document > > (which in the A-imports-B-imports-C example would include components > > that originated from B but NOT those that originated from C). > > Is there > > some reason why you think this approach would be inadequate? > > Well, it would mean that some of the components of B would be > 'incomplete' because the components from C that they refer to would be > missing. Not if B has its own component model, as you go on to suggest . . . > > I wonder if what we actually have is a component model for the root > which includes imported components and a separate component model for > each imported namespace (recurse as necessary). Bingo. I think that approach would be considerably clearer, because there would be a more direct correspondence between each WSDL 2.0 document and its projection into a component model, rather than a single, collapsed component model for all, with special rules that govern which components are supposed to be visible at what points. -- David Booth W3C Fellow / Hewlett-Packard
Received on Monday, 18 April 2005 16:33:00 UTC