- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Tue, 19 Apr 2005 22:49:54 +0200
- 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 UTC