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

RE: Contradictions regarding transitivity of wsdl:import

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Tue, 19 Apr 2005 15:21:04 -0700
Message-ID: <DD35CC66F54D8248B6E04232892B63380579385D@RED-MSG-43.redmond.corp.microsoft.com>
To: "David Booth" <dbooth@w3.org>
Cc: "Arthur Ryman" <ryman@ca.ibm.com>, <www-ws-desc@w3.org>

I would encourage you to NOT diverge from how XSD dealt with this. And
it sounds from the below like you are about to do just that. I don't
object at all to the spec being clear about what's going on, but I think
diverging from what XSD does would be 'a bad thing'.

wsdl:import really is a serialization detail...

Gudge


> -----Original Message-----
> From: David Booth [mailto:dbooth@w3.org] 
> Sent: Tuesday, April 19, 2005 2:27 PM
> To: Martin Gudgin
> Cc: Arthur Ryman; www-ws-desc@w3.org
> Subject: RE: Contradictions regarding transitivity of wsdl:import
> 
> Sorry, but renaming "Description component" to "component model" does
> not clear up the confusion.  The confusion stems from the bizarre
> anachronism of components being in the component model -- which is
> derived *from* the infoset -- even though they were not 
> supposed to have
> been visible at the *infoset* level.  (How can the spec even 
> talk about
> the visibility of components at the infoset level, when components do
> not exist at the infoset level?)   It is almost as though a 
> component is
> supposed to simultaneously exist and not exist in the component model,
> depending on who is referencing it.  Let me demonstrate.
> 
> Suppose I am reading the spec to verify the conformance and meaning of
> document A, which has not imported C.  In particular, I have written
> binding A:bindingA in document/targetNamespace A to reference 
> interface
> C:interfaceC from document/targetNamespace C, and I want to 
> verify that
> I have got it right.  I look at the rules for bindings, sec 2.9.2.2
> says:
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20
> .html?content-type=text/html;%20charset=utf-8#Binding_interfac
> e_attribute
> [[
> The interface attribute information item refers, by QName, to an
> Interface component.
> ]]
> 
> Section 2.9.3 then defines the value of the Binding component's
> {interface} property as:
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20
> .html?content-type=text/html;%20charset=utf-8#Binding_Mapping
> [[
> The Interface component resolved to by the actual value of 
> the interface
> attribute information item, if any.
> ]]
> 
> Section 2.19 then defines QName resolution:
> [[
> . . . QName references are resolved by looking in the appropriate
> property of the Description component. . . .
> If the appropriate property of the Description component does not
> contain a component with the required QName then the reference is a
> broken reference.
> ]]
> 
> One would expect that the reference from A:bindingA to C:interfaceC
> should result in a "broken reference", because A did not 
> import C.  But
> in the current component model, the C:interfaceC component *is* in the
> "appropriate property of the Description component"!  In 
> spite of this,
> it is somehow not supposed to be "visible".
> 
> This doesn't make sense.  It would be much clearer if the component
> model itself reflected the desired visibility of components in QName
> references, such that rules like 2.19 for QName resolution 
> would have a
> transparent interpretation.
> 
> Arthur's option 2 would solve this problem by adopting a more 
> intuitive
> correspondence between the infoset and the component model.
> 
> 
> 
> On Tue, 2005-04-19 at 11:28, Martin Gudgin wrote:
> > 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>
> >         > 
> >         > 
> -- 
> David Booth <dbooth@w3.org>
> 
> 
Received on Tuesday, 19 April 2005 22:21:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:35 GMT