Re: Proposal for Simplifications to the Component Model

Amy,

Yes, I think if we just allow Extension Components at the top level, then 
we can discard Component Equivalence and just use Infoset Equivalence.

The real motivation for introducing the notion of component equivalence, 
was that the same document may get included or imported several times, 
e.g. via diamond inheritance where the base Interface is referenced by 2 
apparently different URLs, or in fact different URLs. For example, you 
might include a copy of the original document.

Given that we were willing to tolerate the above, we could also tolerate 
cuting and pasting of intact top level components, e.g. maybe I wanted to 
have a single WSDL document rather than one that included others.

If these are really the only use cases, then we can just compare the 
infosets when forming the component model. If the infosets agree, then all 
is well, otherwise, we have conflicting definitions. By construction, the 
Component model never contains two equivalent components. Then we have 
constraints that state, for example, that each Interface component is 
uniquely identified by its QName.

The alternative is to allow the Component Model to contain sets of 
equivalent components. Then we have the additional constraint that states, 
for example, that if two Interface components have the same QName then 
they must be equivalent.

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/



Amelia A Lewis <alewis@tibco.com> 
Sent by: www-ws-desc-request@w3.org
01/31/2005 02:48 PM

To
Arthur Ryman/Toronto/IBM@IBMCA
cc
www-ws-desc@w3.org
Subject
Re: Proposal for Simplifications to the Component Model








On Mon, 31 Jan 2005 10:41:18 -0500
Arthur Ryman <ryman@ca.ibm.com> wrote:
> www-ws-desc-request@w3.org wrote on 01/28/2005 06:23:54 PM:

Oooh, a promotion!  *laugh*

> > 1. replace component equivalence with infoset equivalence [is this
> > just for top-level elements?]
> 
> Based on our discussion of the requirement for top-level extension 
> elements and attributes, I don't think infoset equivalence will work.
> The  upshot is that we will have to live with the more complex concept
> of  component equivalence. Here's the reason:
> 
> There are two kinds of extensions that you could put in the top level:
> 1)  extension components, and 2) extension properties. An extension
> component  would presumably to treated like Interface, Binding,
> Service, in the sense  that it becomes something you could refer to,
> but its presence doesn't  alter the semantics of the other components.
> 
> In constrast, an extension property is something that affects the
> other  components, like a Feature or Property component does. I assume
> that you  can put an extension property at the root and its presence
> might affect  some of the other components, i.e. that those other
> components might  acquire some {extension properties}. This is only
> implicit in Part 1.
> 
> Here's an example:
> 
> Document 1:
> <description>
>         <x:reliable/>
>         <interface name="Register"/>
>         <binding name="SOAPRegsiter"/>
> </description>
> 
> Document 2:
> <description>
>         <interface name="Regsiter"/>
>         <binding name="SOAPRegsiter"/>
> </description>
> 
> Assume that the spec for <x:reliable> states that all Bindings
> described  in the document are reliable, but the extension does not
> modify the  semantics of any Interface or Service components.
> 
> Isn't it true then that the two Interface components are equivalent,
> but  the two Binding components are not equivalent?

/me primly refrains from pointing out the spelling discrepancy.

> If you agree with the above, then we can't define equivalence at the 
> infoset level. 

This is because extensions at the top level *may* behave like
features/properties (in scope for all components, effectively), rather
than like components.  You also point out, later in the same email, that
features and properties are not permitted at the top level.

If we were to say that feature/property-like extensions were not allowed
at the top level, would we then be able to use infoset equivalence?

Would it be worthwhile to do so?  Is there a use case for placing a
marker inside "description" in order that it be in scope for its
siblings?  Note that, compared to the scoping rules for features and
properties (which have been criticized for complexity), this is quite
ambiguous, since it effectively relies on either 1) sibling status (the
set of previous-sibling+following-sibling) or 2) document order (but
that's only an inference based on the example, not actually implied in
your discussion).  F&P instead rely on containment, with the additional
linking between service/endpoint <-> binding <-> interface treated as
forms of containment.  But perhaps this is all irrelevant.

Use cases?  Is this the only obstacle to the use of infoset equivalence?

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com