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_interface_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 21:26:58 UTC