- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Tue, 19 Apr 2005 15:21:04 -0700
- 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 UTC