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: Fri, 22 Apr 2005 02:54:43 -0400
To: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
Cc: Roberto.Chinnici@Sun.COM, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, www-ws-desc@w3.org, www-ws-desc-request@w3.org
Message-ID: <OF5C5D9F3C.891C5169-ON85256FEA.0022D1AB-85256FEB.0025F6F3@ca.ibm.com>
Roberto,

I fail to understand what is so attractive about "laziness". It makes 
specifying behavior very difficult.

Another design is to just have an <include> and let it include components 
from the same or other namespaces, but the location must be resolvable. 

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: Roberto.Chinnici@Sun.COM
04/20/2005 07:32 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






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>
Received on Friday, 22 April 2005 06:54:49 GMT

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