RE: Proposal for Simplifications to the Component Model

Arthur,
 
I have a few questions of clarification here,
 
> We should eliminate the concept of component equivalence 
> and use infoset equivalence instead
 
(a) What is information set equivalence?
 
(b) "An XML document has an information set" [1], what is information set
equivalence if multiple documents are involved? (via wsdl:import and
wsdl:include)
 
(c) An instance of the WSDL component model may be constructed by an API,
User Interface, or by mapping from a collection of information sets (via
mapping spelled out in WSDL 20 spec). If an instance of the WSDL component
model is constructed by means other than mapping from a collection of
information sets, there aren't any real information sets, that is, there
aren't any real XML documents. In such cases, what is information set
equivalence?
 
(d) In many instances, in Part 1, mapping brings in default values -
example, [2] "{style}= The set containing the URIs in the actual value of
the style attribute information item if present, otherwise the set
containing the URIs in the actual value of the styleDefault attribute
information item of the [parent] interface element information item if
present, otherwise empty." How does information set equivalence take these
default values (and other such constructs) into account?
 
I looked through this thread and did not find answers for these questions.
 
[1]  <http://www.w3.org/TR/2004/REC-xml-infoset-20040204/#intro>
http://www.w3.org/TR/2004/REC-xml-infoset-20040204/#intro
[2]
<http://www.w3.org/TR/2004/WD-wsdl20-20040803/#InterfaceOperation_Mapping>
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#InterfaceOperation_Mapping
 
Regards,
Asir S Vedamuthu
asirv at webmethods dot com
 <http://www.webmethods.com/> http://www.webmethods.com/ 

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Arthur Ryman
Sent: Thursday, January 27, 2005 3:13 AM
To: www-ws-desc@w3.org
Subject: Proposal for Simplifications to the Component Model



As I mentioned in an earlier note [1], I've hit problems trying to formally
specify some aspects of the component model. These are related to the
interactions between interface inheritance, component equivalence, and
extension elements. I'd like to propose some simplifications here so I can
move forward. 

1. The spec has the notion of component equivalence. This concept was
introduced as a consequence of interface inheritance. The problem was that
we wanted to allow diamond inheritance, eg: 

interface A extends B, C; 
interface B extends D; 
interface C extends D; 

The problem occurs because now it looks like interface A contains two,
potentially conflicting, copies of the operations in D. We resolved this by
saying that if the copy of D acquired via B is equivalent to the copy of D
acquired via C, then all is well. Otherwise there is an error. The two
copies will be equivalent if they come from the same document, which is the
normal case. However, we can't simply compare the URIs used to import or
include D because it is possible to have two different URIs resolve to the
same document. We therefore need to compare the contents of the documents. 

The definition of component equivalence is recursive and can be computed
bottom-up, i.e. two components are equivalent if all their properties are
equivalent. Their properities could be either values or component
references. If component references, then apply this definition recursively
until you hit just values. 

This would be fine if all component properties could be computed bottom-up.
But there are some properties that are computed top-down, e.g. in-scope
Property and Features, or inherited Operation or Fault components. Also,
some Extension component properties might be like this. So the definition is
a little circular and hard to specify simply. 

I'd like to propose a simplification. We should eliminate the concept of
component equivalence and use infoset equivalence instead. In a sense, the
infoset is really where this concept belongs since it arises from
considering how we combine documents. The component model has no concept of
document. It is built up from the infosets of documents. 

The impact of this change is that as we are building up the component model,
we check to see that duplicate definitions of components have equivalent
infosets. If the infosets differ then we have an error and we can't create
the component model. The infoset definition is strictly bottom-up and can be
computed without reference to derived component model properties. 

Furthermore, I suggest we apply this notion only to the top level elements:
interface, binding, and service, since they are the components that are
likely to appear more than once either via import or include or by cut and
paste. 

2. An implication of the above proposal is that we would disallow
"accidental" duplication of operations or faults. For example, the following
situation is disallowed: 

interface A { operation X }; 
interface B extends A { operation X}; 

The above is disallowed since operation X is defined in two different
interfaces. This is disallowed even if the contents of operation (A/X) is
identical to operation (B/X). The appearance of X in B is considered to be
an accident and an error. 

Similarly, the following is also illegal: 

interface A { operation X}; 
interface B { operation X}; 
interface C extends A, B; 

A and B may contain operations of the same name, but an error occurs when C
extends both of them, even if X is defined identically in both. Designers
must factor common operations into a base interface, e.g. 

interface D {operation X}; 
interface A {...}; 
interface B {...}; 
interface C extends A, B; 

The same considerations apply to Fault components. 

An additional motivation for this rule is that now all components have
unique URI's. Everyone component is defined in a unique parent component and
we can assign it a URI by building up a path composed of the names of its
ancestors. In contrast, if we allowed accidental equivalence, then in the
first example, we only have one operation component X, but is has 2 parents
(A and B) and therefore 2 URIs : nsuri#wsdl.operation(A/X) and
nsuri#wsdl.operation(B/X). And we would really have to compute its derived
properties to determine equivalence. 

3. Finally, for this to work, we should only permit extension elements and
attributes in the top level elements: interface, binding, and service. This
means they are disallowed as children of the root description element. 

The motivation for this is that extensions in the root element are scoped to
the document, but there is no way to capture this scope within the component
model. The only property pushed down from the document to the top level
elements is the targetnamespace attribute which becomes the namespace name
of the QNames of interface, binding, and service. 

Allowing root level extensions complicates the definition of infoset
equivalence of the top level elements since the semantics of the extensions
might alter the meanings of the top level element, i.e. attach some
inherited properties to them. 

The consequence is that if an extension is intended to have document wide
scope, then it must be explicitly copied into all the top level elements.
However, I am not aware of any such extensions in use today. 

One other pleasant consequence of this rule is that we can have a
deterministic schema that enforces the order of the top level elements,
i.e.: 

description = 
        (import | include) * 
        types ? 
        (interface | binding | service) * 

This avoids the need to introduce additional elements to enforce order as I
proposed in [2]. 

[1]
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jan/0007.htm
l 
[2]
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jan/0006.htm
l 

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/