W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2005

RE: Contradictions regarding transitivity of wsdl:import

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>

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

Martin Gudgin <mgudgin@microsoft.com>
Arthur Ryman/Toronto/IBM@IBMCA, www-ws-desc@w3.org
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:49 UTC