RE: Proposal for Simplifications to the Component Model

Arthur,

I have follow up questions ..

Related to my question (b)-
> We define equivalence of each type of element at 
> the infoset level, e.g. two <interface> elements 
> are equivalent is they have the same <operation> 
> children in any order, etc. 

<operation> children may or may not be in the same <interface> element
because of interface inheritance. <operation> children may originate from a
different document. That is, multiple documents are involved. What is
information set equivalence if multiple documents are involved via WSDL
import and include? Apologize, if I missed it.

Related to my question (c) -
> The spec deals with infosets, no matter where 
> they come from. They come come from parsing an 
> XML document, or calling the DOM API. That's the 
> whole point of Infosets.

I believe that you missed my question. Let me re-state it. Say, I have an
instance of WSDL component model. I constructed it via an API (definitely
not DOM, a higher level API) or User Interface. There aren't any information
sets or XML documents. In this case, what is information set equivalence?

Related to my question (d) -
> We compare the Infoset after the defaults 
> have been applied. This is Post Schema Validation 
> Infoset. We don't care if an attribute value is 
> actually present or is defined by an attribute. 

Let me bring back the example that I quoted in my previous e-mail, [1]
"{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."

First, Post Schema Validation Information Set cannot help us. This is
complex mapping. This is more than simple attribute value contribution.
Particularly, the phrase "otherwise the set containing the URIs in the
actual value of the styleDefault attribute information item of the [parent]
interface element". BTW, there are many such complex mapping rules.

Second, WSDL 2.0 Last Call draft does not mandate XML Schema validation of
WSDL documents. Right?

That brings back my question (d), How does information set equivalence take
these default values (and other such constructs) into account? Again, these
default values are more than simple attribute value contribution.

[1] http://www.w3.org/TR/2004/WD-wsdl20-20040803/#InterfaceOperation_Mapping

Regards,
Asir S Vedamuthu
asirv at webmethods dot 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: Monday, February 07, 2005 6:15 PM
To: www-ws-desc@w3.org
Subject: RE: Proposal for Simplifications to the Component Model



Asir, 

My responses are below. 

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

Infoset equivalence is something we get to define. The idea is that if there
are two infosets that each contain a definition for the same component, then
we can look at their element and attribute infomation items and decide if
the definitions are the same. I am suggesting we resolve duplicate
definitions at the infoset level rather than the component level. 

Our spec describes how to construct a component model from a set of XML
infosets. We also talk about equivalence of components since the "same"
component may be defined in more than one infoset, e.g. via include, import.


Now consider an Interface component. Suppose it is defined twice. That is OK
as long as the two definitions are equivalent. So we have the following
constraint on the component model: 

Rule A: For all Interface components, x, y, if the QName of x is the same as
the QName of y then x MUST be equivalent to y. 

The alternative to the above rule is to detect equivalence in the infoset
before creating the component model. Why bother having equivalent components
floating around in the model? Then we get the following constraint: 

Rule B: For all Interface components, x, y, if the QName of x is the same as
the QName of y then x MUST be equal to y. 

Rule B is stronger. It says that Interface components are uniquely
identified by their QName within the component model. 

I'd prefer Rule B, but it seems that if we allow arbitrary top level
extension properties then it is very difficult to compute infoset
equivalence. For example, suppose we allow a top level extension property
that says "All bindings defined in this infoset require security." Then we
can just look at the infoset of the bindings when comparing two infosets. We
need to understand the context, which means we need to understand the
component model. In this case we need Rule A. 

>   
> (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) 

We define equivalence of each type of element at the infoset level, e.g. two
<interface> elements are equivalent is they have the same <operation>
children in any order, etc. 

>   
> (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? 

The spec deals with infosets, no matter where they come from. They come come
from parsing an XML document, or calling the DOM API. That's the whole point
of Infosets. 

>   
> (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? 

We compare the Infoset after the defaults have been applied. This is Post
Schema Validation Infoset. We don't care if an attribute value is actually
present or is defined by an attribute. 

But let me say again, there is no general definition of infoset equivalence.
We have to define it for each of our component types. The point is that we
filter out equalivalent definitions before adding them to the component
model. 


>   
> 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 
> [2]
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#InterfaceOperation_Mapping 
>   
> Regards, 
> Asir S Vedamuthu
> asirv at webmethods dot 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.html 
> [2] http://lists.w3.org/Archives/Public/public-ws-desc-
> comments/2005Jan/0006.html 
> 
> 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/

Received on Tuesday, 8 February 2005 20:38:52 UTC