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