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

Re: Contradictions regarding transitivity of wsdl:import

From: David Booth <dbooth@w3.org>
Date: Thu, 21 Apr 2005 23:20:54 -0400
To: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
Cc: Arthur Ryman <ryman@ca.ibm.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, www-ws-desc@w3.org, www-ws-desc-request@w3.org
Message-Id: <1114140054.13968.8428.camel@nc6000.w3.org>

Oops!  I was wrong.   Arthur's example *does* seem to be correct per the
XML Schema spec, as he explained in today's meeting.  The portions I
cited below were correct regarding XML Schema's component model, but
there are *additional* constraints imposed at the infoset level that I
had missed.

Specifically, XML Schema Part 1 sec 3.15.3 "Constraints on XML
Representations of Schemas" describes QName resolution, and says:
http://www.w3.org/TR/xmlschema-1/#src-resolve
[[
. . . the ·namespace name· of the ·QName· is the same as . . .
The ·actual value· of the namespace [attribute] of some <import> element
information item contained in the <schema> element information item of
that schema document.
]]
which is clearly expressed at the *infoset* level.  Thus, in the "A
includes B and B imports C" example, components from C would NOT be
visible to A unless A explicitly imported C.


On Thu, 2005-04-21 at 14:55, David Booth wrote:
> Nice itemization of the characteristics, Roberto!  
> 
> However, I agree with Asir that #6 is a misperception of the XML Schema
> spec.   By my reading of the XML Schema spec, XML Schema <include> *is*
> transitive over <import>.  (If I'm misreading the XML Schema spec, I
> hope somebody will cite appropriate sections to correct me.)  Thus, I
> think the XML Schema parser that Arthur used in his example gave
> incorrect results.
> 
> Here are the relevant sections from the XML Schema spec that lead me to
> this conclusion.  XML Schema Part 1 Sec 4.2.1 describes the meaning of
> <include> as:
> http://www.w3.org/TR/xmlschema-1/#compound-schema
> [[
> The ·XML Schema· corresponding to <schema> contains not only the
> components corresponding to its definition and declaration [children],
> but also all the components of all the ·XML Schemas· corresponding to
> any <include>d schema documents.
> ]]
> 
> and
> [[
> If [the including and included targetNamespace match] then the schema
> corresponding to [the including document] must include not only
> definitions or declarations corresponding to the appropriate members of
> its own [children], but also components identical to all the ·schema
> components· of [the included document].
> ]]
> 
> Therefore <include> would be transitive over <import> iff the schema
> expressed in the included document contains the components from the
> imported document/namespace.  And according to sec 4.2.3, which
> describes <import>, it does:
> http://www.w3.org/TR/xmlschema-1/#composition-schemaImport
> [[
> The ·schema components· . . . of a schema corresponding to a <schema>
> element information item with one or more <import> element information
> items must include not only definitions or declarations corresponding to
> the appropriate members of its [children], but also, for each of those
> <import> element information items . . . , a set of ·schema components·
> identical to all the ·schema components· of [the imported
> document/namespace].
> ]]
> 
> 
> 
> On Wed, 2005-04-20 at 19:32, Roberto Chinnici wrote:
> > I think there is some cognitive dissonance at work here, it's just that
> > we're so used to it we don't see it anymore.
> > 
> > Consider the characteristics of wsdl:import:
> > 1 - makes components in a different target namespace visible
> > 2 - not transitive (i.e. it allows for encapsulation)
> > 3 - lazy (the location URI may not be dereferenceable)
> > 
> > And those of wsdl:include:
> > 4 - makes components in the same target namespace visible
> > 5 - transitive (A includes B includes C => A sees C)
> > 6 - not transitive over imports (A includes B imports C =>
> >     A doesn't see C)
> > 7 - eager ("if the URI indicated by location is not dereferenceable
> >     or does not resolve to a WSDL document then the processor MUST
> >     fail immediately")
> > 
> > I would stipulate that 4/5/7 are typical of an "include" feature,
> > 1/2 of an "import". The lazyness of import (3) seems orthogonal
> > but let's take it as typical here. But 6 clashes with the intuition
> > of include and, I would argue, with the definition of the purpose of
> > wsdl:include in the spec [1]:
> > 
> >    The WSDL include element information item allows for the separation of
> >    different components of a service definition, belonging to the same
> >    target namespace, into independent WSDL documents which can be merged
> >    as needed.
> > 
> > There is no "merging" of documents of any sorts here. wsdl:include
> > operates effectively as a wsdl:import for components in the same
> > namespace as that of the importing documents... except for the 7
> > vs 3 clash!
> > 
> > Now consider the following alternative design: there is only wsdl:import
> > and it's used for both descriptions with the same namespace as the
> > importing one or a different one. It would have properties 1/2/3/4. It
> > would necessarily be lazy (3), being an import. It would obey 6 as well
> > (not transitive). The only missing bit is 7, i.e. when a processor
> > imports a description that has the same namespace of the importing WSDL,
> > it may decide not to access the document at the given location. Suppose
> > we add this special rule, and (surprise!) there is no recognizable
> > "include" anymore.
> > 
> > Conclusion: wsdl:include is an import in disguise and with a deceiving
> > name.
> > 
> > Roberto
> > 
> > [1] 
> > http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#includes
> > 
> > Arthur Ryman wrote:
> > > 
> > > Roberto,
> > > 
> > > I think they are at least self-consistent, if not completely intuitive.
> > > 
> > > The rule for import is that if your document refers to another 
> > > namespace, then you MUST import it, whether or not some document that 
> > > you include already imports it. At least this rule is easy to check.
> > > 
> > > Can you think of any other reason for not having a 1-1 correspondence 
> > > between Description components and documents?
> > > 
> > > 
> > > 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 08:22 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
> > > 
> > > 
> > > 	
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 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>
-- 
David Booth <dbooth@w3.org>
Received on Friday, 22 April 2005 03:21:06 GMT

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