- From: Lawrence Mandel <lmandel@ca.ibm.com>
- Date: Thu, 16 Mar 2006 18:09:45 -0500
- To: "Jonathan Marsh" <jmarsh@microsoft.com>
- Cc: public-ws-desc-comments@w3.org
- Message-ID: <OF56F67EBD.34814BDF-ON85257133.007F2C10-85257133.007F3CF3@ca.ibm.com>
I see that the assertions have been added to the spec so I agree with the
resolution of the issue.
Thanks,
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@ca.ibm.com
"Jonathan Marsh" <jmarsh@microsoft.com>
03/16/2006 05:56 PM
To
Lawrence Mandel/Toronto/IBM@IBMCA
cc
<public-ws-desc-comments@w3.org>
Subject
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?content-type=text/html;%20charset=utf-8#assertionsummary
[ Jonathan Marsh ][ jmarsh@microsoft.com ][
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
Received on Thursday, 16 March 2006 23:09:58 UTC