RE: Contradictions regarding transitivity of wsdl:import

OK, just wanted to make sure I'd understood the proposal. I think that
change is fine. If such a minor change clears up the confusion, I'm all
for it!!!

Gudge


________________________________

	From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
	Sent: Tuesday, April 19, 2005 8:18 AM
	To: Martin Gudgin
	Cc: David Booth; www-ws-desc@w3.org; www-ws-desc-request@w3.org
	Subject: RE: Contradictions regarding transitivity of
wsdl:import
	
	

	Gudge, 
	
	That's what I am proposing. What's your opinion? 
	
	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/ 
	
	
	
"Martin Gudgin" <mgudgin@microsoft.com> 
Sent by: www-ws-desc-request@w3.org 

04/19/2005 10:35 AM 

To
Arthur Ryman/Toronto/IBM@IBMCA 
cc
"David Booth" <dbooth@w3.org>, <www-ws-desc@w3.org>,
<www-ws-desc-request@w3.org> 
Subject
RE: Contradictions regarding transitivity of wsdl:import

	




	So, to summarize; the plan is to rename, at the component model
level, the 'Description' component to be called the 'Component Model'
component? 
	  
	Gudge 
	
	
________________________________

	From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
	Sent: Tuesday, April 19, 2005 6:07 AM
	To: Martin Gudgin
	Cc: David Booth; www-ws-desc@w3.org; www-ws-desc-request@w3.org
	Subject: RE: Contradictions regarding transitivity of
wsdl:import
	
	
	Martin, 
	
	After your note, David phoned me and we talked for a long time.
The conversation pointed out to me that what I considered to be the
obvious interpretation of the component model was not so obvious. 
	
	My interpretation was that the Description component contained
all the components from all the documents. i.e., we are only talking
about a single component model instance. Any reference from one
component must land on another component within the same Description
component. 
	
	However, David thought that the Description component mapped
more closely to the <description> element and that it contained only
those components that were "visible" to the components defined in the
document. 
	
	I think this confusion could be reduced by adopting Option 1,
namely get rid of the Description component and replace it with a new
object named "Component Model". That would make is clear that there is
no close correspondence with a document. 
	
	The Component Model object would contain the same properties as
the current Description component. These properties contain the "root"
components: interfaces, bindings, services, and types. All other
components are nested within the root components. 
	
	Option 1 also has the benefit that we finally define the
Component Model in the same amount of detail as we define the
components. The spec refers to the component model a lot but never
actually defines in much detail. 
	
	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/ 
	
	
"Martin Gudgin" <mgudgin@microsoft.com> 
Sent by: www-ws-desc-request@w3.org 

04/18/2005 09:56 PM 



To
"David Booth" <dbooth@w3.org>, Arthur Ryman/Toronto/IBM@IBMCA 
cc
<www-ws-desc@w3.org> 
Subject
RE: Contradictions regarding transitivity of wsdl:import


	


	
	
	
	
	I didn't think this was where we ended up after my
'illumination'
	e-mail... What happened? 
	
	Gudge
	
	> -----Original Message-----
	> From: David Booth [mailto:dbooth@w3.org] 
	> Sent: Monday, April 18, 2005 6:53 PM
	> To: Arthur Ryman
	> Cc: Martin Gudgin; www-ws-desc@w3.org
	> Subject: RE: Contradictions regarding transitivity of
wsdl:import
	> 
	> On Mon, 2005-04-18 at 12:17, Arthur Ryman wrote:
	> > 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..
	> 
	> I now understand that that is the current design of the
component
	> model.  I was suggesting that instead there should be a 
	> component model
	> for each WSDL 2.0 document (i.e., each wsdl:description
element
	> information item), along the lines of option 2 that you
propose below.
	> 
	> > 
	> > 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
	> 
	> Yes, I think this approach would be a considerably clearer and
more
	> straightforward way to go.  However, I would nitpick about the
word
	> "set".  "Directed graph" would be more precise:  A given WSDL
2.0
	> document would have a single Description component, which may
refer to
	> other Description components (if the original WSDL 2.0 
	> document imports
	> other documents, for example), thus representing a directed
graph.
	> 
	> > 
	> > This makes the mapping between Description components and
documents
	> > clearer. 
	> 
	> Yes, and we need people to understand our spec.  We have
already
	> received complaints about how hard it is to understand.   
	> 
	> > 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).
	> 
	> I think we have that subtlety already, but you're right it 
	> will have to
	> be resolved differently.  There are several ways it could be 
	> handled.  I
	> doubt equivalence classes would be needed.  One way is for
each
	> Description component to have an {imported descriptions} 
	> property.  Then
	> if a new document is imported, ignore it if its corresponding
	> Description component is already in that set.
	> 
	> 
	> -- 
	> David Booth <dbooth@w3.org>
	> 
	>