RE: FW: Component Values Must Be Context Independent

Tony,

The WSDL 2.0 spec makes no statements about components being earlier or 
later. There is no processing model. It just says that certain assertions 
must hold among a set of components and their properties. The parser will 
build up a set of components and their properties. A validator can check 
if all the assertions are satisfied. 

We'd have to consult the WS-Addressing spec to answer your specific 
questions. It is up to the extension spec to be clear about its own 
assertions.

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
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



"Rogers, Tony" <Tony.Rogers@ca.com> 
Sent by: www-ws-desc-request@w3.org
05/30/2006 09:40 PM

To
Arthur Ryman/Toronto/IBM@IBMCA, "Jonathan Marsh" <jmarsh@microsoft.com>
cc
<www-ws-desc@w3.org>, <www-ws-desc-request@w3.org>
Subject
RE: FW: Component Values Must Be Context Independent






Subtle point, but I think I get it. You are suggesting that when we 
encounter the usingAddressing extension on the Endpoint we check whether 
the (earlier) Interface has been correctly annotated with those properties 
- if it has not, then we throw a fault?
 
Does this imply that we must accept properties on the Interface (relating 
to usingAddressing) without knowing if they will be engaged? And is it an 
error (I suspect NOT) if those properties appear on the Interface even 
when usingAddressing does NOT appear on the Endpoint or Binding?
 
Tony Rogers
tony.rogers@ca.com
 

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On 
Behalf Of Arthur Ryman
Sent: Wednesday, 31 May 2006 11:06
To: Jonathan Marsh
Cc: www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: RE: FW: Component Values Must Be Context Independent


Jonathan, 

Are you saying that the <wsa:UsingAddressing /> extension on the Endpoint 
causes additional properties to be added to the Interface Message 
Reference and the Interface Fault Reference? If so, then this would be 
outlawed by my proposal. 

However, if the interprettation is that those components need to have 
those other properties when using this extension, then this is permitted 
since those components don't actually change. 

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
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 


"Jonathan Marsh" <jmarsh@microsoft.com> 
Sent by: www-ws-desc-request@w3.org 
05/30/2006 06:52 PM 


To
Arthur Ryman/Toronto/IBM@IBMCA 
cc
<www-ws-desc@w3.org> 
Subject
RE: FW: Component Values Must Be Context Independent








Thanks for the explanation ? seems quite clear. 
  
However, I?m now worried about this change?s impact on the WS-Addressing 
WSDL extensions [1]. 
  
The presence of the wsaw:UsingAddressing extension causes the addition of 
an {addressing} property on a Binding or Endpoint Component.  This 
optional property signals that WS-Addressing use has been declared.  Once 
it is declared (so I infer) other corresponding properties are REQUIRED, 
for instance {action} which appears on Interface Message Reference and 
Interface Fault Components. 
  
So, if I my description looks like this: 
  
<wsdl:description ?> 
            <wsdl:import namespace=?i? location=?interface.wsdl?/> 
            <wsdl:import namespace=?b? location=?binding.wsdl?/> 
            <wsdl:service interface=?i:interface?> 
                        <wsdl:endpoint binding=?b:binding? ?> 
<wsaw:UsingAddressing required=?true?/> 
                        </wsdl:endpoint> 
            <wsdl:service>
</wsdl:description> 
  
It looks like the presence of wsaw:UsingAddressing as an endpoint 
extension results in the addition of properties to the imported interface 
components.   Does this example seem overly contrived?  Would it be 
outlawed under your proposal? 
  
[1] 
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8 

  
  



From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
Sent: Monday, May 29, 2006 8:24 PM
To: Jonathan Marsh
Cc: www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: Re: FW: Component Values Must Be Context Independent 
  

Jonathan, 

Yes, we should use consistent terminology. 

There are 3 kinds of components: 

1) The root Description component, which is in a category by itself 
2) Top-level components: Interface, Binding, Service, Element Declaration, 
and Type Definition - these are contained in the Description component 
3) Nested components: everything else - these all have a {parent} 
property. 

When talking about component equivalence, we are really mainly interested 
in the Top-level components since we can get name collisions when we 
combine documents. Name collisions are impossible within a document by 
virtue of the schema. A document would be invalid if it had name conflicts 
and we wouldn't get past the XML infoset stage. 

However, when we combine two or more documents, we need to avoid name 
conflicts. It's OK to have two Top-level components with the same name in 
two different documents as long as they are equivalent. That way we avoid 
the conflict. We need an efficient way to test for equivalence. We'd like 
to be able to decide if two components are equivalent just by examing 
their documents, not any other documents they might reference via import 
or include. 

A property is a name-value pair. A component has a set of properties such 
that each property has a unique name. 

Note that all components have some combination of property values that 
defines a key, i.e. in a valid component model instance, that combination 
of values uniquely identifies the component. For example, all the 
top-level components have QName keys, i.e. the {name} property. The spec 
does define this for every component although it doesn't explicitly call 
them keys. I gave a table of these in my orginal note. The keys are used 
in the XML infoset to refer to components. The keys are used in the 
component designators. 

Two components are equivalent if and only if: 
1) they have the same set of property names 
2) for each of their property names, the corresponding values are 
equivalent. 

So now we have boiled down the definition to that of value equivalence. 

There are two kinds of values: 
1) Component values - single or optional components, sets or lists of 
components. In general we can regard these as collections of components by 
treating single components as singleton sets. 
2) Non-component values - everything else. Let's call these scalar values. 
These are things like strings, tokens, uri's, etc. They are often XML 
simple types. 

Two scalar values are equivalent if and only if they are equal. 

That leaves the definition of equivalence for component values. Since 
these are collections, we first require that the collections are 
"isomorphic" i.e. that there is an invertible mapping from one to the 
other (which is just the natural correspondence for lists in the case of 
ordered collections). Further, we require that the mapping relates 
equivalent components where we define equivalence as follows: 

There are two kinds of components: 
1) child components - these are nested components whose {parent} property 
is equal to the component that contains the property under consideration 
2) non-child components - all other components 

Two non-child component values are equivalent if their keys are equal. 
This means we don't have to inspect the contents of other documents. 
Within a document, one component references another via its key, e.g. its 
QName. 
Two child component values are equivalent if they are equivalent as 
components - this is the recursive step. But we always recurse down the 
parent-child tree so the definition is non-circular and it terninates. 

I claim that this definition of equivalence agrees with the old definition 
when applied to the component model instance as a whole. 

However, the new definition is weaker since it might state that a specific 
pair of components are equivalent while the old definition says they are 
inequivalent. This is because the new definition just compares keys in 
some cases. 

For example suppose in a component model instance we have 4 interfaces 
where A extends B and A' extends B'. Suppose all interfaces are in 
different documents and that document of A includes document of B, and 
document of A' includes document of B'. Suppose A and A' as interfaces 
have identical infosets. Suppose B and B' have the same QNames but differ 
in some other respect. The equivalence relations are as follows: 

  
old 
new 
A and A' 
not equivalent 
equivalent 
B and B' 
not equivalent 
not equivalent



Even though the new definition reports that A and A' are equivalent, the 
component model as a whole is invalid. Furthermore, by just flagging B and 
B' as inequivalent, we get a more useful error message, since by 
inspection A and A' look identical. 

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
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 

"Jonathan Marsh" <jmarsh@microsoft.com> 
Sent by: www-ws-desc-request@w3.org 
05/23/2006 03:53 PM 


To
<www-ws-desc@w3.org> 
cc
  
Subject
FW: Component Values Must Be Context Independent

  


  
 





[Random keystroke sent it too early, and then got interrupted by hours of 
telcons ? completed below.] 
  

  



From: Jonathan Marsh 
Sent: Tuesday, May 23, 2006 10:07 AM
To: 'Arthur Ryman'
Cc: www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: RE: Component Values Must Be Context Independent 
 
OK, just trying to understand the terminology.  The spec doesn?t use the 
term ?child component?.  It does use the term ?nested components? which 
are non-top-level components (e.g. any component but Description, 
Interface, Binding, Service, Element Declaration, and Type Definition.) 
2.17 for instance talks about ?references to other components? but doesn?t 
really define the term, which you seem to be specializing into ?child? and 
?non-child? components. 
 
So, a child component property is 
a)       A property of component X, 
b)      with a value of a component, set of components, or list of 
components, 
c)       where each of the components in (b) having a parent property, 
d)      and where each of these parent property has a value of component 
X. 
Is that right? 
 
The reason for trying to get clarity here is that we haven?t distinguished 
between properties that contain components ?by value? and those that 
contain components ?by reference?, which is IMO an implementation choice. 
We chose one strategy for serializing the graph as a tree for the 
interchange format but that?s just one choice. 
 
Is the categorization below correct? 
 
Another observation: comparing the value of the ?value? property involves 
an infoset comparison, about which I don?t see anything in 2.17. 
 
 
Child component property 
Non-component property 
Non-child component property 
 
(properties missing from the table below) 
interface operation  |  Binding Operation.{interface operation} 
binding message references  |  Binding Operation.{binding message 
references} 
binding fault reference   |  Binding Operation.{binding fault references} 
Interface message references | Binding Message Reference.{interface 
message references} 
Interface fault reference  |  Binding Fault Reference.{interface fault 
reference} 
  

Property
Where Defined
address 
Endpoint.{address} 
binding 
Endpoint.{binding} 
binding faults 
Binding.{binding faults} 
binding operations 
Binding.{binding operations} 
bindings 
Description.{bindings} 
direction 
Interface Fault Reference.{direction}, Interface Message Reference.{
direction} 
element declaration 
Interface Fault.{element declaration}, Interface Message Reference.{
element declaration} 
element declarations 
Description.{element declarations} 
endpoints 
Service.{endpoints} 
extended interfaces 
Interface.{extended interfaces} 
features 
.{features}, Binding.{features}, Binding Fault.{features}, Binding Fault 
Reference.{features}, Binding Message Reference.{features}, Binding 
Operation.{features}, Endpoint.{features}, Interface.{features}, Interface 
Fault.{features}, Interface Fault Reference.{features}, Interface Message 
Reference.{features}, Interface Operation.{features}, Service.{features} 
interface 
Binding.{interface}, Service.{interface} 
interface fault 
Binding Fault.{interface fault}, Interface Fault Reference.{interface 
fault} 
interface fault references 
Interface Operation.{interface fault references} 
interface faults 
Interface.{interface faults} 
interface message references 
Interface Operation.{interface message references} 
interface operations 
Interface.{interface operations} 
interfaces 
Description.{interfaces} 
message content model 
Interface Message Reference.{message content model} 
message exchange pattern 
Interface Operation.{message exchange pattern} 
message label 
Interface Fault Reference.{message label}, Interface Message Reference.{
message label} 
name 
.{name}, Binding.{name}, Element Declaration.{name}, Endpoint.{name}, 
Interface.{name}, Interface Fault.{name}, Interface Operation.{name}, 
Service.{name}, Type Definition.{name} 
parent 
.{parent}, Binding Fault.{parent}, Binding Fault Reference.{parent}, 
Binding Message Reference.{parent}, Binding Operation.{parent}, Endpoint.{
parent}, Feature.{parent}, Interface Fault.{parent}, Interface Fault 
Reference.{parent}, Interface Message Reference.{parent}, Interface 
Operation.{parent}, Property.{parent} 
properties 
.{properties}, Binding.{properties}, Binding Fault.{properties}, Binding 
Fault Reference.{properties}, Binding Message Reference.{properties}, 
Binding Operation.{properties}, Endpoint.{properties}, Interface.{
properties}, Interface Fault.{properties}, Interface Fault Reference.{
properties}, Interface Message Reference.{properties}, Interface 
Operation.{properties}, Service.{properties} 
ref 
Feature.{ref}, Property.{ref} 
required 
Feature.{required} 
services 
Description.{services} 
style 
Interface Operation.{style} 
system 
Element Declaration.{system}, Type Definition.{system} 
type 
Binding.{type} 
type definitions 
Description.{type definitions} 
value 
Property.{value} 
value constraint 
Property.{value constraint} 

 
  

  



From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
Sent: Tuesday, May 23, 2006 8:57 AM
To: Jonathan Marsh
Cc: www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: RE: Component Values Must Be Context Independent 
 

Jonathan, 

Yes, there is a {parent} property for each child component. The idea is 
that to compute equivalence, you look at the non-reference properties and 
the child components. You compare the reference properties by value, i.e. 
don't traverse into the referenced component if it is not a child. This 
let's you compute equivalence based on the contents of the document that 
contains the enclosing top-level component, i.e. you don't have to look at 
other documents. 

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
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 

"Jonathan Marsh" <jmarsh@microsoft.com> 
Sent by: www-ws-desc-request@w3.org 
05/22/2006 08:20 PM 
  


To
Arthur Ryman/Toronto/IBM@IBMCA, <www-ws-desc@w3.org> 
cc
 
Subject
RE: Component Values Must Be Context Independent


  


 
 





Can you explain a bit more the difference between so-called ?child 
components? and ?non-child components??  I couldn?t find these 
distinguished clearly in the spec.  Do you just mean the parent property? 
  


  




From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On 
Behalf Of Arthur Ryman
Sent: Thursday, April 20, 2006 4:20 PM
To: www-ws-desc@w3.org
Subject: Component Values Must Be Context Independent 


Components can be brought into a component model instance through <import> 
and <include>. For scalability purposes, it is highly desirable for the 
value of a component to be independent of the context that it was brought 
it. 

The use case is a development tool for SOA applications that needs to 
support hundreds or thousands of services. The tool needs to validate the 
service definitions. The requirement is that the time to do this be 
linear. We are currently experiencing performance problems validating 
large sets of WSDL 1.1 documents. We need to have an spec-compliant 
optimization for WSDL 2.0. 

Ideally, a tool should be able to compute the components directly defined 
in a document without looking at any of the imports or includes. There are 
two problems now that prevent this: 

1. In theory, we allow extensions that could alter the semantics of 
imported or included components. However, there is no requirement or use 
case for this flexibility, much less a realistic, compelling one. Note 
that this is actually a real problem in XML Schema, e.g. due to "features" 
such as cameleon includes, and <redefine>, you need to know the context in 
which a document is included. 

2. The current definition of component equivalence is recursive in the 
sense that to test if two components are equivalent, it is necessary to 
determine if all of the components they refer to are equivalent. In effect 
this means that you have to construct the entire component model instance 
in order to resolve the references to the other components. 

Since WSDL documents typically include or import others, a collection of 
WSDL documents is likely to be moderately connected when viewed as a 
graph. Therefore, when you validate the collection, you end up processing 
a given document many times in general. You process it a number of times 
equal to the number of documents that refer to it directly or indirectly 
(+ 1). This is non-linear. The exact degree of non-linearity depends on 
how connected the graph is. Consider a simple chain of n WSDL documents. 

A1 includes A2 includes A3 includes ... An 

Validating A1 requires reading n documents. 
Validating A2 requires reading n-1 documents. 
... 
Validating An requires reading 1 document. 

Therefore validating the whole set of documents requires readiing n + 
(n-1) + ... + 1 = n(n+1)/2 = O(n^2), i.e. this is quadratic, not linear. 

On the other hand, if the meaning if each document is independent of how 
it is used then a smart tool could cache the results and only read n 
documents. 

The fix is as follows: 

1. Add the following assertion. An extension MUST NOT affect the value of 
components that are added to the component model via <import> or 
<include>. 
2. State the definition of component equivalence as follows. Two 
components are equivalent when: 
     A) All of their child components are equivalent. 
     B) All of their non-component properties are equal. 
     C) All of their non-child component properties refer to components 
that have the same keys (e.g. names). 
The difference is that to test for equivalence, you only have to look at a 
component's value-based properties and child components. You don't have to 
traverse the component graph, which might take you into another document. 
You only have to compare referred to components via their keys. 

We then add a statement to each component explicitly stating what its key 
values are. This is straight-forward. We already implicitly defined keys 
when stating uniqueness rules, i.e. each Interface component in a 
Description component must have a unique {name}. The key is usually the 
{name} property. For Features and Properties, it is the {ref} property. 
The complete list is: 

1. ElementDeclaration: {name} 

2. TypeDefinition: {name} 

3. Interface: {name} 

4. InterfaceFault: {name} 

5. InterfaceOperation: {name} 

6. InterfaceMessageReference: {message label} 

7. InterfaceFaultReference: {interface fault}.{name}. {message label} 

8. Binding: {name} 

9. BindingFault: {interfaceFault}.{name} 

10. BindingOperation: {interfaceOperation}.{name} 

11. BindingMessageReference: {interface message reference}.{message label} 


12. BindingFaultReference: {interface fault reference}.{interface 
fault}.{name}, {interface fault reference}.{message label} 

13 Service: {name} 

14. Endpoint: {name} 

15. Feature: {ref} 

16. Property: {ref} 

In general, any extension component that might be refered to needs to 
define a key value, since that is how the reference is represented in the 
XML serialization. 

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
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