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

Thanks for your comment.  The WS Description Working Group tracked this
issue as a CR001 [1].  The Working Group agreed to add these assertions
to the spec.  They SHOULD ;-) be present in the latest draft [2].

 

Unless you let us know otherwise by 13 April, we will assume you agree
with the resolution of this issue.

 

[1] http://www.w3.org/2002/ws/desc/5/cr-issues/#CR001

[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?cont
ent-type=text/html;%20charset=utf-8#assertionsummary

 

 [  Jonathan Marsh  ][  jmarsh@microsoft.com
<mailto:jmarsh@microsoft.com>   ][  http://spaces.msn.com/auburnmarshes
<http://spaces.msn.com/auburnmarshes>   ]

 

________________________________

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Lawrence Mandel
Sent: Thursday, November 17, 2005 2:06 PM
To: www-ws-desc@w3.org
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