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: Wed, 20 Apr 2005 09:31:11 -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: <OFE22EC33B.921017AB-ON85256FE9.0049DC9D-85256FE9.004A42B2@ca.ibm.com>
David/Gudge,

I am NOT proposing to change any semantics. The proposal is a change to 
the Component Model to make the visibility rules clearer.

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/19/2005 10:01 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







I didn't think option 2 was proposing to change the semantics of
wsdl:import.  My intent was simply to adopt a different strategy for
describing the semantics in the WSDL component model.


On Tue, 2005-04-19 at 18:21, Martin Gudgin wrote:
> 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>
> > 
> > 
-- 
David Booth <dbooth@w3.org>
Received on Wednesday, 20 April 2005 13:31:15 GMT

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