- 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 UTC