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: Fri, 22 Apr 2005 16:15:20 -0400
To: Matt Long <mlong@mvsquared.net>
Cc: Roberto Chinnici <Roberto.Chinnici@Sun.COM>, Arthur Ryman <ryman@ca.ibm.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, www-ws-desc@w3.org
Message-Id: <1114200920.13968.8527.camel@nc6000.w3.org>

Matt,

Yes, that appears to be correct according to the XML Schema spec,
bizarre as it may seem, and wsdl:include is modeled after the XML Schema
xs:include.   

A rough (but I think fair) characterization of wsdl:include is that it
is a WSDL-aware include mechanism with certain exemptions -- neither a
lexical include nor a simple WSDL-aware include.  Until yesterday it
exempted:
	1. element declarations;
	2. type definitions; and   
	3. imported components.

#1 and #2 above were originally exempted (by Part 1 table 2-1 in sec
2.1.3 [1]) because that is what XML Schema does, though the WG decided
yesterday to include them also, so that all rows in table 2-1 will have
similar treatment under wsdl:include.

#3 above is still exempted (by Part 1 sec 4.2 [2]) because that is what
XML Schema does.  The wording in sec 4.2 is admittedly not as clear
about this as it should be, but the WG (as of yesterday) intends to
improve it.

Incidentally, by saying the things above are "exempted" during
wsdl:include, I mean that wsdl:include does not cause them to become
accessible from the including document even though they were accessible
from the included document.

References
1. Sec 2.1.3:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#Description_Mapping
2. Sec 4.2:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#imports

On Fri, 2005-04-22 at 05:00, Matt Long wrote:
> David et.al.
> 
> For sake of clarity...are you stated that for the case A includes B
> imports C
> that namespace of C is not visible to A even though A <include> B, and
> therefore an <include>  of B is omitting <import> of C in A.
> 
> Thx,
> 
> --
> Matt Long
> MV Squared Technologies
> mlong@mvsquared.net
> 901-848-2640
> 
> 
>         --------- Original Message --------
>         From: "David Booth" <dbooth@w3.org>
>         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
>         Subject: Re: Contradictions regarding transitivity of
>         wsdl:import
>         Date: 21/04/05 21:19
>         
>         
>         
>         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>
>         
>         
>         
>         
>         
>         
>         
>         
> 
> 
> ________________________________________________
> This message has been sent via webmail.
> Please forward unsolicited email (spam) to...
abuse@hostonce.com
-- 
David Booth <dbooth@w3.org>
Received on Friday, 22 April 2005 20:15:39 GMT

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