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

RE: Contradictions regarding transitivity of wsdl:import

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Tue, 19 Apr 2005 22:49:54 +0200
Message-ID: <99CA63DD941EDC4EBA897048D9B0061D1324CDFF@uspalx20a.pal.sap.corp>
To: "Roberto Chinnici" <Roberto.Chinnici@Sun.COM>, "Arthur Ryman" <ryman@ca.ibm.com>
Cc: <www-ws-desc@w3.org>, <www-ws-desc-request@w3.org>

+1
 

-----Original Message-----
From: Roberto Chinnici [mailto:Roberto.Chinnici@Sun.COM] 
Sent: Tuesday, Apr 19, 2005 1:49 PM
To: Arthur Ryman
Cc: Yalcinalp, Umit; 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 Tuesday, 19 April 2005 20:50:06 GMT

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