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

Received on Monday, 31 January 2005 19:48:24 UTC