Re: types, description, interface, feature, and property assertions

Lawrence,

Thx for the assertions. I'll apply these.

Next time, would you like to try marking up the spec and attaching it and 
a CVS patch? That might be faster for both of us.

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



Lawrence Mandel/Toronto/IBM@IBMCA 
Sent by: www-ws-desc-request@w3.org
11/17/2005 05:05 PM

To
www-ws-desc@w3.org
cc

Subject
types, description, interface, feature, and property assertions







I'd like to suggest the addition of the following types, description, 
interface, feature, and property assertions to the WSDL 2.0 spec, appendix 
E. For each entry I've listed a suggested id, the assertion, and the 
location of the assertion in the spec.: 
(*note: I've included some assertions that do not contain "MUST" but still 
seem as though they are requirements of  instances of the WSDL 2.0 spec.)


types-0023 
Section 3.2 
A specification of extension syntax for an alternative schema language 
MUST include the declaration of an element information item, intended to 
appear as a child of the wsdl:types element information item, which 
references, names, and locates the schema instance (an ?import? element 
information item). 

description-0024 
Section 2.1.2 
Each WSDL 2.0 or type system component MUST be uniquely identified by its 
qualified name. That is, if two distinct components of the same kind 
(Interface, Binding, etc.) are in the same target namespace, then their 
QNames MUST be unique. However, different kinds of components (e.g., an 
Interface component and a Binding component) MAY have the same QName. 
Thus, QNames of components must be unique within the space of those 
components in a given target namespace. 

description-0025 
Section 2.1.2.1 
The type of the targetNamespace attribute information item is xs:anyURI. 
Its value MUST be an absolute IRI (see [IETF RFC 3987]). 

types-0026 
Section 2.1.2.1 
It is an error if there are multiple type definitions for each QName. 

interface-0027 
Section 2.2.1 
To avoid circular definitions, an interface MUST NOT appear as an element 
of the set of interfaces it extends, either directly or indirectly. 

interface-fault-0028 
Section 2.2.1 
The namespace name of the {name} property of each Interface Fault in this 
set MUST be the same as the namespace name of the {name} property of this 
Interface component. 

interface-operation-0029 
Section 2.2.1 
The namespace name of the {name} property of each Interface Operation in 
this set MUST be the same as the namespace name of the {name} property of 
this Interface component. 

interface-0030   
Section 2.2.1 
For each Interface component in the {interfaces} property of a Description 
component, the {name} property MUST be unique. 

interface-0031 
Section 2.2.2.3 
The type of the styleDefault attribute information item is list of 
xs:anyURI. Its value, if present, MUST contain absolute IRIs (see [IETF 
RFC 3987]). 

interface-fault-0032 
Section 2.3.1 
For each Interface Fault component in the {interface faults} property of 
an Interface component, the {name} property must be unique. Interface 
Fault components are uniquely identified by the the QName of the enclosing 
Interface component and QName of the Interface Fault component itself. 

interface-fault-0033 
Section 2.3.1 
In cases where, due to an interface extending one or more other 
interfaces, two or more Interface Fault components have the same value for 
their {name} property, then the component models of those Interface Fault 
components MUST be equivalent (see 2.17 Equivalence of Components). 

interface-fault-0034 
Section 2.3.1 
Note that, due to the above rules, if two interfaces that have the same 
value for the namespace name of their {name} property also have one or 
more faults that have the same value for their {name} property then those 
two interfaces cannot both form part of the derivation chain of a derived 
interface unless those faults are the same fault. 

interface-operation-0035 
Section 2.4.1 
For each Interface Operation component in the {interface operations} 
property of an Interface component, the {name} property MUST be unique. 
Interface Operation components are uniquely identified by the the QName of 
the enclosing Interface component and QName of the Interface Operation 
component itself. 

interface-operation-0036 
Section 2.4.1 
In cases where, due to an interface extending one or more other 
interfaces, two or more Interface Operation components have the same value 
for their {name} property, then the component models of those Interface 
Operation components MUST be equivalent (see 2.17 Equivalence of 
Components). 

mep-0037 
Section 2.4.1.1 
A message exchange pattern is uniquely identified by an absolute IRI which 
is used as the value of the {message exchange pattern} property the 
Interface Operation component, and it specifies the fault propagation 
ruleset that its faults obey. 

interface-operation-0038 
Section 2.4.1.2 
An Interface Operation component MUST satisfy the specification defined by 
each operation style identified by its {style} property. If no Interface 
Operation component can simultaneously satisfy all of the styles, the 
document is invalid. 

message-label-0039 
Section 2.5.1 
The value of this property MUST match the name of a placeholder message 
defined by the message exchange pattern. 

interface-message-ref-0040 
Section 2.5.1 
The direction MUST be the same as the direction of the message identified 
by the {message label} property in the {message exchange pattern} of the 
Interface Operation component this is contained within. 

interface-message-ref-0041 
Section  2.5.1 
When the {message content model} property has the value #any or #none the 
{element declaration} property MUST be empty. 

interface-message-ref-0042 
Section 2.5.1 
For each Interface Message Reference component in the {interface message 
references} property of an Interface Operation component, its {message 
label} property MUST be unique. 

interface-fault-ref-0043 
Section 2.6.1 
The value of this property MUST match the name of a placeholder message 
defined by the message exchange pattern. 

interface-fault-ref-0044 
Section 2.6.1 
The direction MUST be consistent with the direction implied by the fault 
propagation ruleset used in the message exchange pattern of the operation. 


interface-fault-ref-0045   
Section 2.6.1 
For each Interface Fault Reference component in the {interface fault 
references} property of an Interface Operation component, the combination 
of its {interface fault} and {message label} properties MUST be unique. 

feature-ref-0046   
Section 2.7.1 
This xs:anyURI MUST be an absolute IRI as defined by [IETF RFC 3987]. 

feature-ref-0047 
Section 2.7.1 
The {ref} property of a Feature component MUST be unique within the 
{features} property of an Interface, Interface Fault, Interface Operation, 
Interface Message Reference, Interface Fault Reference, Binding, Binding 
Fault, Binding Operation, Binding Message Reference, Binding Fault 
Reference, Service, or Endpoint component. 

property-ref-0048 
Section 2.8.1 
This xs:anyURI MUST an absolute IRI as defined by [IETF RFC 3987]. 

property-0049 
Section 2.8.1 
A reference to a Type Definition component in the {type definitions} 
property of the Description component constraining the value of the 
Property, or the token #value if the {value} property is not empty. 

property-0050 
Section 2.8.1 
The {ref} property of a Property component MUST be unique within the 
{properties} property of an Interface, Interface Fault, Interface 
Operation, Interface Message Reference, Interface Fault Reference, 
Binding, Binding Fault, Binding Operation, Binding Message Reference, 
Binding Fault Reference, Service, or Endpoint component. 

property-0051 
Section 2.8.1.1 
However, it is in general feasible to test specified values for either 
equality or membership in value sets. All specified values MUST be equal 
and belong to each specified value set.


Lawrence Mandel

Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814   Fax: 905 - 413 - 4920
lmandel@ca.ibm.com