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