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

Re: Contradictions regarding transitivity of wsdl:import

From: Arthur Ryman <ryman@ca.ibm.com>
Date: Tue, 19 Apr 2005 18:08:34 -0400
To: www-ws-desc@w3.org
Message-ID: <OF5D3B66EC.94AEA2F7-ON85256FE8.00784F26-85256FE8.0079A14C@ca.ibm.com>
Roberto,

Here is an XSD example that shows how <xs:include> works. It shows that 
when one document includes another, it doesn't bring in the <xs:import>. 
This is why I think we need a Description component for each document, 
i.e. so we can express the visibility rules.

B1.xsd defines a global element Business in namespace B. It is valid.

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace=
"http://www.ibm.com/B" xmlns:tns="http://www.ibm.com/B">
        <element name="Business" type="string"/>
</schema>

A1.xsd defines a global element Address1 in namespace A. It references 
b:Business and <xs:import>s B1.xsd. It is valid.

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        targetNamespace="http://www.ibm.com/A" xmlns:tns=
"http://www.ibm.com/A"
        xmlns:b="http://www.ibm.com/B">
        <import namespace="http://www.ibm.com/B" schemaLocation="B1.xsd"
></import>
        <element name="Address1">
                <complexType>
                        <sequence>
                                <element ref="b:Business"/>
                        </sequence>
                </complexType>
        </element>
</schema>

A2.xsd defines a global element Address2 in namespace A. If references 
b:business and <xs:include>s A1.xsd. It is invalid.

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        targetNamespace="http://www.ibm.com/A" xmlns:tns=
"http://www.ibm.com/A"
        xmlns:b="http://www.ibm.com/B">
        <include schemaLocation="A2.xsd"/>
        <element name="Address2">
                <complexType>
                        <sequence>
                                <element ref="b:Business"/>
                        </sequence>
                </complexType>
        </element>
</schema>

Here's the error message:

src-resolve.4.2: Error resolving component 'b:Business'. It was detected 
that 'b:Business' is in namespace 'http://www.ibm.com/B', but components 
from this namespace are not referenceable from schema document 'A2.xsd'. 
If this is the incorrect namespace, perhaps the prefix of 'b:Business' 
needs to be changed. If this is the correct namespace, then an appropriate 
'import' tag should be added to 'A2.xsd'


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/



Arthur Ryman/Toronto/IBM@IBMCA 
Sent by: www-ws-desc-request@w3.org
04/19/2005 05:45 PM

To
Roberto Chinnici <Roberto.Chinnici@Sun.COM>
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







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 Tuesday, 19 April 2005 22:08:39 GMT

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