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

Re: Contradictions regarding transitivity of wsdl:import

From: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
Date: Tue, 19 Apr 2005 17:22:33 -0700
To: Arthur Ryman <ryman@ca.ibm.com>
Cc: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, www-ws-desc@w3.org, www-ws-desc-request@w3.org
Message-id: <4265A0C9.8090006@sun.com>

Indeed, I send it before I saw your XSD example. But what if (gasp!)
XML Schema got it wrong?

Roberto

Arthur Ryman wrote:
> 
> Roberto,
> 
> I guess you wrote this before I sent my detailed XSD example. The 
> behavior I described is how XSD works. Includes DO NOT  bring in 
> imports.In the example below A3 cannot see B1.
> 
> 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/
> 
> 
> *Roberto Chinnici <Roberto.Chinnici@Sun.COM>*
> Sent by: www-ws-desc-request@w3.org
> 
> 04/19/2005 06:19 PM
> 
> 	
> To
> 	Arthur Ryman/Toronto/IBM@IBMCA
> cc
> 	"Yalcinalp, Umit" <umit.yalcinalp@sap.com>, www-ws-desc@w3.org, 
> www-ws-desc-request@w3.org
> Subject
> 	Re: Contradictions regarding transitivity of wsdl:import
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> By the argument I made in my previous email, the rule you describe
> is wrong and should be changed. I.e. in
> 
>  > Let A1 import B1.
>  > Let A3 include A1 and A2.
> 
> components in B1 should be visible in all of A3.
> 
> Components in B1 would not be visible in A2 if the latter was processed
> as a stand-alone description, but they would be visible there when A2 is
> processed indirectly as a consequence of its inclusion in A3.
> 
> Roberto
> 
> Arthur Ryman wrote:
>  >
>  > Roberto,
>  >
>  > Unfortunately, if we treat <include> the way you'd like, then we run
>  > into problems wrt to visibility.
>  >
>  > Let A and B be different namespaces.
>  >
>  > Let  A1, A2, A3, and B1 be documents for the corresponding namespaces.
>  > Let A3 be the root document.
>  >
>  > Let A1 import B1.
>  > Let A3 include A1 and A2.
>  >
>  > If we only have 2 Description components (for A and B), then we can't
>  > express that fact that the components defined in B1 are not visible to
>  > the components defined in A2.
>  >
>  > BTW, my interpretation of include is that it only applies to the WSDL
>  > components and not to any imports or types defined in the document. An
>  > import must be lexically present in any document that references
>  > components from another namespace.
>  >
>  > If this example, it would be illegal for a component directly defined in
>  > A3 to reference a component defined in B1, even though A3 includes A1
>  > which imports B1.
>  >
>  > I could simplify the example as:
>  >
>  > Let A1 import B1.
>  > Let A2 include A1.
>  >
>  > The we lose the fact that B1 is not visible to the component directly
>  > defined in A2.
>  >
>  > 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/
>  >
>  >
>  > *Roberto Chinnici <Roberto.Chinnici@Sun.COM>*
>  > Sent by: www-ws-desc-request@w3.org
>  >
>  > 04/19/2005 04:49 PM
>  >
>  >                  
>  > To
>  >                  Arthur Ryman/Toronto/IBM@IBMCA
>  > cc
>  >                  "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, 
> www-ws-desc@w3.org,
>  > www-ws-desc-request@w3.org
>  > Subject
>  >                  Re: Contradictions regarding transitivity of wsdl:import
>  >
>  >
>  >                  
>  >
>  >
>  >
>  >
>  >
>  >
>  > Arthur,
>  >
>  > I agree with everything you wrote wrt import, but I think that "include"
>  > should do exactly that, i.e. collect pieces of a description spread over
>  > several documents and produce just one description component.
>  >
>  > In other words, wsdl:include should be invisible from a component
>  > model point of view: a single-document description and an equivalent
>  > one spread over multiple documents for authoring convenience should
>  > be indistinguishable. As evidence, I would point to the fact that given
>  > a single description component, a tool should be free to serialize it as
>  > a single document or as multiple ones (using wsdl:include).
>  >
>  > IMHO, that's the whole idea behind any inclusion facility, regardless of
>  > the particular language to which it applies. Otherwise, it shouldn't
>  > be called "include".
>  >
>  > Roberto
>  >
>  >
>  > Arthur Ryman wrote:
>  >  >
>  >  > Roberto,
>  >  >
>  >  > Option 2, which makes a closer connection between Description 
> components
>  >  > and <description> documents introduces some additional questions.
>  >  >
>  >  > I suggest that we have a 1-1 correspondence between Description
>  >  > components and documents, and that we would model the <import> and
>  >  > <include> elements as relations between Description documents. Each
>  >  > Description component would only include the components directly 
> defined
>  >  > in the corresponding document.
>  >  >
>  >  > I'd add the following properties to Description:
>  >  >
>  >  > {location} the URI of the document
>  >  > {target namespace} the absolute URI target namespace of the document
>  >  > {imports} a set of Description components that this document imports
>  >  > {includes} a set of Description components that this document includes
>  >  >
>  >  > If a namespace is deemed to be well-known in some context, i.e. the
>  >  > <import> gives no explicit @location, then the processor can 
> assign it a
>  >  > synthetic {location}.
>  >  >
>  >  > A Component Model is then a non-empty set of Description 
> components with
>  >  > one Description component distinguished as the root. Each Description
>  >  > component is uniquely identified by its {location} property. The
>  >  > Description components form a connected, directed graph wrt the 
> imports
>  >  > and includes relation. Each Description MUST be reachable from the 
> root
>  >  > Description component.
>  >  >
>  >  > We can express the visibility rules wrt to the import and include
>  >  > relations.
>  >  >
>  >  > This raises the question of how to handle equivalent components. I
>  >  > suggest that one only allow one instance of any top-level 
> component, and
>  >  > we allow more than more Description component to refer to it. For
>  >  > example, if document1 and document2 both contained equivalent 
> interface1
>  >  > components then both document1 and document2 would refer to the same
>  >  > interface1 component. This fits well with the {parent} property since
>  >  > the top level components do not have parents.
>  >  >
>  >  >
>  >  > 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/
>  >  >
>  >  >
>  >  > *Roberto Chinnici <Roberto.Chinnici@Sun.COM>*
>  >  > Sent by: www-ws-desc-request@w3.org
>  >  >
>  >  > 04/19/2005 01:35 PM
>  >  >
>  >  >                  
>  >  > To
>  >  >                  "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
>  >  > cc
>  >  >                  www-ws-desc@w3.org
>  >  > Subject
>  >  >                  Re: Contradictions regarding transitivity of 
> wsdl:import
>  >  >
>  >  >
>  >  >                  
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >
>  >  > I don't like this name change either.
>  >  >
>  >  > Besides the confusion caused by the proposed name change, I find 
> option
>  >  > 2 in Arthur's email a lot more appealing. Since David Booth called it
>  >  > "a considerably clearer and more straightforward way to go", I would
>  >  > suggest that examine it more carefully. My impression is that by
>  >  > aligning the description component with the intuitive concept of a
>  >  > description document, it will make things easier to grok for users.
>  >  > The issues around component equivalence don't seem unsolvable.
>  >  >
>  >  > By the way, I'm assuming that if we go with option 2, wsdl:include 
> would
>  >  > not cause a second Description component with the same targetNamespace
>  >  > as the including document to appear but would simply add components to
>  >  > the existing one.
>  >  >
>  >  > Roberto
>  >  >
>  >  >
>  >  > Yalcinalp, Umit wrote:
>  >  >  > Wouldn't this "name change" appear to imply that there are multiple
>  >  >  > component models rather than multiple descriptions? That is more
>  >  >  > confusing rather than clarifying IMO.
>  >  >  >  
>  >  >  > -1
>  >  >  >  
>  >  >  > --umit
>  >  >  >  
>  >  >  >
>  >  >  >    
>  >  > 
> ------------------------------------------------------------------------
>  >  >  >     *From:* www-ws-desc-request@w3.org
>  >  > [mailto:www-ws-desc-request@w3.org]
>  >  >  >     *Sent:* Tuesday, Apr 19, 2005 8:29 AM
>  >  >  >     *To:* Arthur Ryman
>  >  >  >     *Cc:* David Booth; www-ws-desc@w3.org; 
> www-ws-desc-request@w3.org
>  >  >  >     *Subject:* RE: Contradictions regarding transitivity of
>  > wsdl:import
>  >  >  >
>  >  >  >     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>
Received on Wednesday, 20 April 2005 00:21:14 GMT

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