This specification, Web Services Policy 1.5 - Attachment, defines two general-purpose mechanisms for associating policies, as defined in Web Services Policy 1.5 - Framework, with the subjects to which they apply. This specification also defines how these general-purpose mechanisms may be used to associate policies with WSDL and UDDI descriptions.
On 28 February 2007, this specification
Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This specification will remain a Candidate Recommendation until at least 30 June 2007.
This Working Draft was produced by the members of the
A list of
The Working Group is tracking all comments via
This document was produced by a group operating under the
Last Modified: $Date: 2007/03/29 13:03:59 $
The Web Services Policy 1.5 - Framework [
To enable Web Services Policy to be used with existing Web
service technologies, this specification describes the use of
these general-purpose mechanisms with WSDL [
This section specifies the notations, namespaces, and terminology used in this specification.
This specification uses the following syntax within normative outlines:
The syntax appears as an XML instance, but values in
Characters are appended to elements and attributes to indicate cardinality:
"?" (0 or 1) "*" (0 or more) "+" (1 or more)
The character "|" is used to indicate a choice between alternatives.
The characters "(" and ")" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice.
This document relies on the XML Information Set [
XML namespace prefixes (see
The ellipses characters "…" are used to indicate a point of extensibility that allows other Element or Attribute Information Items.
Elements and Attributes defined by this specification are referred to in the text of this document using XPath 1.0 [XPATH 1.0] expressions. Extensibility points are referred to using an extended version of this syntax:
An element extensibility point is referred to using {any} in place of the element name. This indicates that any element name can be used, from any namespace other than the http://www.w3.org/ns/ws-policy namespace.
An attribute extensibility point is referred to using @{any} in place of the attribute name. This indicates that any attribute name can be used, from any namespace. namespace.
Normative text within this specification takes precedence over
normative outlines, which in turn take precedence over the XML Schema
[
This specification uses a number of namespace prefixes throughout; they are
listed in
Prefix | XML Namespace | Specification |
---|---|---|
mtom
|
http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization
| [ |
rmp
|
http://docs.oasis-open.org/ws-rx/wsrmp/200602
| [ |
sp
|
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy
| [ |
wsa
|
http://www.w3.org/2005/08/addressing
| [ |
wsap
|
http://www.w3.org/2006/05/addressing/wsdl
| [ |
wsdl11
|
http://schemas.xmlsoap.org/wsdl/
| [ |
wsdl20
|
http://www.w3.org/2006/01/wsdl
| [ |
wsoap12
|
http://schemas.xmlsoap.org/wsdl/soap12/
| [ |
(none), wsp
|
http://www.w3.org/ns/ws-policy
| This specification |
wsse
|
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
| [ |
wsu
|
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
| [ |
xs
|
http://www.w3.org/2001/XMLSchema
| [ |
All information items defined by this specification
are identified by the XML namespace URI [
In this document reference is made to the
It is the intent of the W3C Web Services Policy Working Group that the Web Services Policy 1.5 - Framework and Web Services Policy 1.5 - Attachment XML namespace URI will not change arbitrarily with each subsequent revision of the corresponding XML Schema documents as the specifications transition through Candidate Recommendation, Proposed Recommendation and Recommendation status. However, should the specifications revert to Working Draft status, and a subsequent revision, published as a WD, CR or PR draft, results in non-backwardly compatible changes from a previously published WD, CR or PR draft of the specification, the namespace URI will be changed accordingly.
Under this policy, the following are examples of backwards compatible changes that would not result in assignment of a new XML namespace URI:
Addition of new global element, attribute, complexType and simpleType definitions.
Addition of new elements or attributes in locations covered by a previously specified wildcard.
Modifications to the pattern facet of a type definition for which the value-space of the previous definition remains valid or for which the value-space of the preponderance of instance would remain valid.
Modifications to the cardinality of elements for which the value-space of possible instance documents conformant to the previous revision of the schema would still be valid with regards to the revised cardinality rule.
The keywords "
We introduce the following terms that are used throughout this document:
The
The
An
A
A
A
A
A
A
A
A
ignorable_policy_assertion
policy
policy_alternative
policy_assertion
policy_expression
policy_subject
policy_scope
policy_attachment
This specification defines several mechanisms for
associating policies (Web Services Policy 1.5 - Framework, [
The document containing both of these policy expressions is
assumed to be located at
http://www.example.com/policies
. Per Section
http://www.example.com/policies#RmPolicy
and
http://www.example.com/policies#X509EndpointPolicy
,
for the examples in
This section defines two general-purpose mechanisms for
associating
In addition it defines the processing rules for scenarios where multiple policies are attached to a policy subject.
When multiple attachments are made, their relevent policies can be combined.
This combination can be achieved through a merge.
Such calculated policy expressions have no meaningful IRI of their own.
This section defines two general-purpose mechanisms for
associating policies [
The
It is often desirable to associate
Since
This specification defines a global attribute that allows
The namespace URI [http://www.w3.org/ns/ws-policy
.
The
An example of
If the
have been processed and
Note that this
The presence of the
Alternatively, rather than using the global attribute, XML elements
This mechanism allows
This element has three components: the
Domain expressions identify the domain of the association. That is,
the set of
For the purposes of attaching
The following is the pseudo-schema for the
The following describes the attributes and elements listed in the pseudo-schema outlined above:
This describes an external
This required element's children describe the
These child elements
This element is a
This element references a
This element is of type
Additional attributes
Other child elements for binding constructs
Domain expressions are used to identify entities such as endpoints, messages or resources with which a policy can be associated. For example, domain expressions may be used to refer to WSDL 1.1 definitions, WSDL 2.0 components, endpoint references, etc.
The following example illustrates the use of this mechanism with an
EndpointReference domain expression for a deployed endpoint as defined
in Web Services Addressing [
In this example, the http://www.example.com/policies#RmPolicy
applies to all
interactions with the endpoint at
http://www.example.com/acct
.
This section defines a domain expression for identifying resources as
The following describes the URI domain expression element listed in the pseudo-schema outlined above:
This element is an IRI that references a resource
as a
Additional attributes
URI domain expressions are used to identify resources that are identified using
IRI or IRI References (such as endpoint, message or operation definitions) with which
IRI References for WSDL 2.0 components
are defined in Appendix C of the Web Services Description Language (WSDL) Version 2.0
Part 1: Core Language [
In this example, the http://www.example.com/policies#RmPolicy
applies to all interactions with
the endpoint at http://example.org/TicketAgent.wsdl20#wsdl.endpoint(TicketAgentService/Endpoint)
.
IRI References for WSDL 1.1 elements are defined in WSDL 1.1 Element Identifiers
[
The scope of URI domain expressions for WSDL 2.0 components or WSDL 1.1
elements is limited to the subjects defined in
Section
Policy attachment mechanisms use IRIs for some identifiers. This
document does not define a base URI but relies
on the mechanisms defined in XML Base [
This section describes a mechanism for associating policy expressions with Web service constructs in WSDL 1.1 [
A model for attaching policies to WSDL 1.1 constructs. The model defines:
A partitioning of WSDL constructs into service, endpoint, operation
and message policy subjects.
The semantics of attaching a
How to combine policies attached to more than one WSDL construct
within a single policy subject.
An XML representation of policy expressions attached to WSDL 1.1 constructs.
The annotation of such policy expressions as required extensions using the
WSDL-defined extensibility flag
WSDL 1.1 disallows the use of extensibility elements on certain elements and
the use of extensibility attributes on others. However, the WS-I Basic Profile 1.1
[
If it is necessary to include the actual
To ensure that consumers of policy-annotated WSDL elements are
capable of processing such @wsdl11:required="true"
attribute).
The rest of this section defines how to interpret the
When attaching a
Figure 1 represents how the
For abstract WSDL definitions, the
Policies that are attached to a deployed resource (e.g., services
or ports) are only considered in the
(This graphic is also available in SVG format
When attaching policies at different levels of the WSDL hierarchy, care must be taken.
A message exchange with an endpoint
For example, in
It is
For any given port, the
The rest of this section describes these
The following WSDL 1.1 element is considered as the service policy subject:
This element
A policy associated with a service policy subject applies to any message exchange using any of the endpoints offered by that service.
The following WSDL 1.1 elements collectively describe an endpoint:
These elements
Since the
Policies associated with an endpoint policy subject apply to any message exchange made using that endpoint.
The
The following WSDL 1.1 elements collectively describe an operation:
These elements
The
Since the
Policies associated with an operation policy subject apply to the message exchange described by that operation.
The
The following WSDL 1.1 elements are used to describe messages:
These elements
The
Policies associated with a message policy subject apply to that message (i.e. input, output or fault message).
The
For example, the
Since a
Since
Care should be taken when attaching policies to outbound messages
as the result may not be what is expected. For example, expressing a
choice on a service's outbound message without a mechanism for a
requester of that service to communicate its choice to the service
before the outbound message is sent may not result in the desired
behaviours. It is therefore
As an example of the combination of these
For endpoints bound to StockQuoteSoapBinding
, the GetLastTradePrice
operation, an additional
message-level
This section describes a mechanism for associating policy expressions with Web service constructs in WSDL 2.0. The mechanism consists of:
A model for attaching policies to WSDL 2.0 constructs. The model defines: A partitioning of WSDL constructs into service, endpoint, operation
and message policy subjects. The semantics of attaching a policy to each policy subject. How to combine policies attached to more than one WSDL component
within a single policy subject.
An XML representation of policy expressions attached to WSDL 2.0 constructs.
The annotation of such policy expressions as required extensions using the
WSDL-defined extensibility flag @wsdl20:required
.
The example below illustrates the use of WS-Policy Attachment for WSDL 2.0:
The SecureBinding
WSDL binding description describes a binding for
an interface that provides real-time quotes and book information on securities.
(The prefixes wsdl20
and tns
are used here to denote
the Web Services Description Language 2.0 XML Namespace and the target namespace
of this WSDL document respectively.) To require the use of security for these
offerings, a endpoint
that supports this binding description.
The RealTimeDataPort
WSDL endpoint description describes an endpoint
that supports the SecureBinding
WSDL binding description. To
require the use of addressing and allow the use of optimization (Optimized MIME
Serialization as defined in the MTOM specification [RealTimeDataPort
endpoint.
In the above example, the #secure
and #common
SecureBinding
WSDL binding and
RealTimeDataPort
WSDL endpoint descriptions collectively apply
to any message exchange associated with the RealTimeDataPort endpoint. The
example below represents the combination of these two RealTimeDataPort
endpoint.
Policy attachment points in a WSDL 2.0 document are:
wsdl20:service
wsdl20:endpoint
wsdl20:binding
wsdl20:binding/wsdl20:operation
wsdl20:binding/wsdl20:fault
wsdl20:binding/wsdl20:operation/wsdl20:input
wsdl20:binding/wsdl20:operation/wsdl20:output
wsdl20:binding/wsdl20:operation/wsdl20:infault
wsdl20:binding/wsdl20:operation/wsdl20:outfault
wsdl20:interface
wsdl20:interface/wsdl20:operation
wsdl20:interface/wsdl20:fault
wsdl20:interface/wsdl20:operation/wsdl20:input
wsdl20:interface/wsdl20:operation/wsdl20:output
wsdl20:interface/wsdl20:operation/wsdl20:infault
and
wsdl20:interface/wsdl20:operation/wsdl20:outfault.
Any of these elements wsp:Policy
or
wsp:PolicyReference
child elements.
Policy attachment points in a WSDL document are associated with specific
Policy Attachment Point in a WSDL document | WSDL Component | Policy Subject |
---|---|---|
wsdl20:service
| Service | Service |
wsdl20:endpoint
| Endpoint | Endpoint |
wsdl20:binding
| Binding | |
wsdl20:interface
| Interface | |
wsdl20:binding/wsdl20:operation
| Binding Operation | Operation |
wsdl20:interface/wsdl20:operation
| Interface Operation | |
wsdl20:binding/wsdl20:operation/ wsdl20:input
| Binding Message Reference | Message for an input message |
wsdl20:interface/wsdl20:operation/wsdl20:input
| Interface Message Reference whose {direction} property is ‘in’ | |
wsdl20:binding/wsdl20:operation/ wsdl20:output
| Binding Message Reference | Message for an output message |
wsdl20:interface/wsdl20:operation/ wsdl20:output
| Interface Message Reference whose {direction} property is ‘out’ | |
wsdl20:binding/wsdl20:fault
| Binding Fault | Message for an input fault message |
wsdl20:binding/wsdl20:operation/ wsdl20:infault
| Binding Fault Reference | |
wsdl20:interface/wsdl20:fault
| Interface Fault | |
wsdl20:interface/wsdl20:operation/wsdl20:infault
| Interface Fault Reference whose {direction} property is ‘in’ | |
wsdl20:binding/wsdl20:fault
| Binding Fault | Message for an output fault message |
wsdl20:binding/wsdl20:operation/wsdl20:outfault
| Binding Fault Reference | |
wsdl20:interface/wsdl20:fault
| Interface Fault | |
wsdl20:interface/wsdl20:operation/wsdl20:outfault
| Interface Fault Reference whose {direction} property is ‘out’ |
For a WSDL component, the attached
A
The common mechanism of associating a wsp:PolicyReference
element. A policy attachment
to a WSDL element is represented by attaching a wsp:PolicyReference
element as a child element of the WSDL element.
wsp:Policy
elements are
included as children of the wsdl20:description
element after the
wsdl20:types
element and referenced using the
wsp:PolicyReference
elements.
To mandate the processing of a @wsdl20:required
flag.
If the wsp:Policy
elements are included as children of the
wsdl20:description
element, these Policy elements @wsdl20:required
. (Note: these
wsdl20:description
element and may not be attached to any policy attachment point in a WSDL
document.)
This document adds an optional {policy} property to the following WSDL components:
Service
Endpoint
Binding
Binding Operation
Binding Fault
Binding Message Reference
Binding Fault Reference
Interface
Interface Operation
Interface Fault
Interface Message Reference
Interface Fault Reference
The {policy} property, when present, represents the capabilities and requirements
as a
Component | Value |
---|---|
Service | A wsp:Policy or
wsp:PolicyReference elements, if any, in the
[children] of the wsdl20:service
element. |
Endpoint | A wsp:Policy or
wsp:PolicyReference elements, if any, in the
[children] of the wsdl20:endpoint
element. |
Binding | A wsp:Policy or
wsp:PolicyReference elements, if any, in the
[children] of the wsdl20:binding
element. |
Binding Operation | A wsp:Policy or
wsp:PolicyReference elements, if any, in the
[children] of the
wsdl20:binding/wsdl20:operation element. |
Binding Fault | A wsp:Policy or
wsp:PolicyReference elements, if any, in the
[children] of the
wsdl20:binding/wsdl20:fault element. |
Binding Message Reference | A wsp:Policy or
wsp:PolicyReference elements, if any, in the
[children] of the
wsdl20:binding/wsdl20:operation/wsdl20:input or
wsdl20:binding/wsdl20:operation/wsdl20:output
element. |
Binding Fault Reference | A wsp:Policy or
wsp:PolicyReference elements, if any, in the
[children] of the
wsdl20:binding/wsdl20:operation/wsdl20:infault
or wsdl20:binding/wsdl20:operation/wsdl20:outfault
element. |
Interface | A wsp:Policy or
wsp:PolicyReference elements, if any, in the
[children] of the wsdl20:interface
element. |
Interface Operation | A wsp:Policy or
wsp:PolicyReference elements, if any, in the
[children] of the
wsdl20:interface/wsdl20:operation element, if
any. |
Interface Fault | A wsp:Policy or
wsp:PolicyReference elements, if any, in the
[children] of the
wsdl20:interface/wsdl20:fault element. |
Interface Message Reference | A wsp:Policy or
wsp:PolicyReference elements, if any, in the
[children] of the
wsdl20:interface/wsdl20:operation/wsdl20:input
or wsdl20:interface/wsdl20:operation/wsdl20:output
element. |
Interface Fault Reference | A wsp:Policy or
wsp:PolicyReference elements, if any, in the
[children] of the
wsdl20:interface/wsdl20:operation/wsdl20:infault
or
wsdl20:interface/wsdl20:operation/wsdl20:outfault
element. |
Two {policy} properties are equivalent when they represent policies that
contain the same number of
Two
Two
The following diagram illustrates the four
If multiple
The
The
An Endpoint component that describes the endpoint,
The Binding component in the Endpoint component’s {binding} property,
The Interface component in the Service component’s {interface} property of the Endpoint component’s {parent} property and
The Interface components in the {extended interfaces} property of the Interface component in the Service component’s {interface} property of the Endpoint component’s {parent} property.
If the Binding component has an Interface component in the {interface}
property, then the
The Interface Operation component that describes the operation and
The Binding Operation component (if any) whose {interface operation} property has the Interface Operation component.
If the Binding component does not have an Interface component in the
{interface} property, then the
If the Binding component has an Interface component in the {interface}
property, then the
The Interface Message Reference component that describes the input message and
The Binding Message Reference component whose {interface message reference} property has the Interface Message Reference component.
If the Binding component does not have an Interface component in the
{interface} property, then the
If the Binding component has an Interface component in the {interface}
property, then the
The Interface Message Reference component that describes the output message and
The Binding Message Reference component whose {interface message reference} property has the Interface Message Reference component.
If the Binding component does not have an Interface component in the
{interface} property, then the effective policy of an output message
If the Binding component has an Interface component in the {interface}
property, then the
The Interface Fault Reference component that describes the input fault message,
The Interface Fault component in the Interface Fault Reference component’s {interface fault} property,
The Binding Fault Reference component whose {interface fault reference} property has the Interface Fault Reference component and
The Binding Fault component whose {interface fault} property has the Interface Fault component in the Interface Fault Reference component’s {interface fault} property.
If the Binding component does not have an Interface component in the
{interface} property, then the
The Interface Fault Reference component that describes the input fault message and
The Interface Fault component in the Interface Fault Reference component’s {interface fault} property.
If the Binding component has an Interface component in the {interface}
property, then the
The Interface Fault Reference component that describes the output fault message,
The Interface Fault component in the Interface Fault Reference component’s {interface fault} property,
The Binding Fault Reference component whose {interface fault reference} property has the Interface Fault Reference component and
The Binding Fault component whose {interface fault} property has the Interface Fault component in the Interface Fault Reference component’s {interface fault} property for the endpoint.
If the Binding component does not have an Interface component in the
{interface} property, then the
The Interface Fault Reference component that describes the output fault message and
The Interface Fault component in the Interface Fault Reference component’s {interface fault} property.
This section defines a mechanism for associating policies with
There are essentially two approaches for registering policies in
UDDI. One approach is to directly reference remotely accessible
When attaching a
Each
For UDDI tModels that represent Web service types, the
Policies that apply to deployed Web services (bindingTemplates) are
only considered in the
Each of these entities
The following UDDI element is considered as the service provider policy subject:
This element
Policy attached to the service provider policy subject applies to behaviors or aspects of the service provider as a whole, irrespective of interactions over any particular service. This includes — but is not limited to — acting as a service consumer or a service provider in general.
The following UDDI element is considered as the service policy subject:
This element
Policy attached to the service policy subject applies to behaviors or aspects of the service as a whole, irrespective of interactions over any particular endpoint. This includes — but is not limited to — acting as a consumer or a provider of the service.
The following UDDI elements collectively describe an endpoint:
These elements
An endpoint policy subject applies to behaviours associated with an entire endpoint of the service, irrespective of any message exchange made. This includes — but is not limited to — aspects of communicating with or instantiating the endpoint.
The
UDDI tModels provide a generic mechanism for associating arbitrary
metadata with services and other entities in a UDDI registry. To
properly integrate Web Services Policy into the UDDI model, Web Services Policy 1.5 - Attachment
pre-defines one tModel that is used to associate a remotely accessible
This new tModel is called the remote policy reference category
system and is defined in Appendix
UDDI registries uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1
to uniquely identify this
tModel so that UDDI registry users can expect the same behavior across
different UDDI registries.
The tModel's valid values are those IRIs that identify external
Using the remote policy reference category system, one can then
associate a http://www.example.com/myservice/policy
with a
The
A different approach has to be taken to associate a
The
In addition to using the approach outlined in the section above,
publishers may register a specific
The following illustrates a tModel for the http://www.example.com/myservice/policy
.
The first "policy"
, which is its single valid value. This is necessary
in order to enable UDDI inquiries for
Note that the
Web Services Policy 1.5 - Attachment pre-defines another tModel that is used to
associate such a pre-registered, locally available
This new tModel is called the local policy reference category
system and is defined in Appendix
UDDI registries uuid:5da4fc61-a302-35ad-91d3-775150429035
to uniquely identify this
tModel so that UDDI registry users can expect the same behavior across
different UDDI registries.
The local policy reference category system is based on tModelKeys. The valid values of this category system are those tModelKeys identifying tModels that
exist in the same UDDI registry
and are categorized as "policy"
using the Web Services Policy Types category system.
That is, when referencing this category system in a category bag,
the corresponding
Given the local policy reference category system, one can then
associate a "uuid:04cfa…"
from above with a
The
A different approach has to be taken to associate a
The tModelKey of the
UDDI Version 3 [
First, the tModelKeys of the pre-defined tModels are migrated to domain-based keys. The migration is unique since the Version 2 keys introduced in this specification are already programmatically derived from the Version 3 keys given below.
The "uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1"
to
"uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference"
.
The "uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941"
to "uddi:w3.org:ws-policy:v1.5:attachment:policytypes"
.
The "uuid:5da4fc61-a302-35ad-91d3-775150429035"
to "uddi:w3.org:ws-policy:v1.5:attachment:localpolicyreference"
.
Second, rather than putting
Third, inquiries for reusable http://www.example.com/
, the following find_tModel
API call can
be used:
Fourth, all UDDI entities may be digitally signed using XML digital
signatures [
It is
Policies
A more complete discussion of security considerations can be found in the
Security Considerations section of the Web Services Policy 1.5 - Framework document [
An element information item whose namespace name is "http://www.w3.org/ns/ws-policy" and whose local part is PolicyAttachment conforms to this specification if it is valid according to the XML Schema [
A WSDL 1.1 [
A WSDL 2.0 [
This section contains the UDDI tModel definitions for the canonical
tModels used in Section
This tModel is used to attach a
Name: |
|
---|---|
Description: | Category system used for UDDI entities to point to an external Web services policy attachment policy that describes their characteristics. See Web Services Policy 1.5 - Attachment specification for further details. |
UDDI Key (V3): |
uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference
|
UDDI V1,V2 format key: |
uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1
|
Categorization: | categorization |
Checked: | No |
This tModel is used to categorize tModels as representing "policy"
, that
indicates this very fact. It is
Name: |
|
---|---|
Description: | Web services policy types category system used for UDDI tModels to
characterize them as Web services policy–based |
UDDI Key (V3): |
uddi:w3.org:ws-policy:v1.5:attachment:policytypes
|
UDDI V1,V2 format key: |
uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941
|
Categorization: | categorization |
Checked: | No |
This tModel is used to attach a
Name: |
|
---|---|
Description: | Category system used for UDDI entities to point to a Web services
policy |
UDDI Key (V3): |
uddi:w3.org:ws-policy:v1.5:attachment:localpolicyreference
|
UDDI V1,V2 format key: |
uuid:5da4fc61-a302-35ad-91d3-775150429035
|
Categorization: | categorization |
Checked: | Yes |
This document is the work of the
Members of the Working Group are (at the time of writing, and by alphabetical order): Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Jeffrey Crump (Sonic Software), Glen Daniels (Sonic Software), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporation), Bob Natale (MITRE Corporation), David Orchard (BEA Systems, Inc.), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Skip Snow (Citigroup), Yakov Sverdlov (CA Inc.), Mark Temple-Raston (Citigroup), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
Previous members of the Working Group were: Jeffrey Crump (Sonic Software), Jong Lee (BEA Systems, Inc.), Bob Natale (MITRE Corporation), Bijan Parsia (University of Manchester), Seumas Soltysik (IONA Technologies, Inc.).
The people who have contributed to
A list of major editorial changes since the Working Draft dated 28 February, 2007 is below:
Aligned the UDDI names and keys with the XML namespace name of the Web Services Policy language.
Date | Author | Description |
---|---|---|
20060712 | ASV | Updated the list of editors. Completed action items
|
20060712 | DBO | Completed action item |
20060718 | DBO | Completed action items
Editors to remove extraneous namespace decl in the example at the end of section 3.4 |
20060719 | TIB | Completed action item |
20060721 | ASV | Completed action items
|
20060721 | ASV | Completed action item
|
20060726 | ASV | Incorporated the
|
20060808 | DBO | Completed action items: |
20060808 | ASV | Implemented the
|
20060809 | DBO | Implemented the
|
20060809 | ASV | Implemented the
|
20060811 | DBO | Completed action items: |
20060813 | ASV | Added a new Section |
20060825 | PY | Implemented the
|
20060827 | TIB | Completed action item:
|
20060827 | TIB | Implemented the
|
20060829 | ASV | Implemented the
|
200609006 | DBO | Completed partial resolution for issue
|
20060906 | ASV | Implemented the
|
20060924 | TIB | Implemented the
|
20060925 | ASV | Created |
20061002 | DBO | Implemented the
|
20061002 | DBO | Implemented the
|
20061008 | MH | Implemented the
|
20061012 | PY | Updated "Changes in this Version" section (Appendix D) |
20061019 | PY | Completed action item:
|
20061027 | FS | Changed the SVG link and re-formatted the examples in
|
20061030 | DBO | Implemented the
|
20061031 | TIB | Completed action item:
|
20061102 | ASV | Implemented the
|
20061102 | ASV | Reset Section |
20061109 | PY | Implemented the
|
20061109 | TIB | Implemented Editors' Action
|
20061109 | ASV | Implemented the
|
20061109 | ASV | Implemented the
|
20061109 | ASV | Updated Section |
20061127 | ASV | Added
|
20061218 | FJH | Implemented the
|
20070108 | ASV | Applied the |
20070108 | ASV | Reset Section |
20070116 | DBO | Completed action item:
|
20070117 | FJH | Applied the resolution for issues 4045 and 4127 using |
20070121 | MH | Completed action item:
|
20070122 | ASV | Implemented the resolution for issue |
20070122 | UY | Implemented the resolution for issue |
20070122 | UY | Implemented the resolution for issue |
20070123 | ASV | Applied |
20070123 | ASV | Applied a |
20070123 | ASV | Fixed a typo in |
20070124 | ASV | Updated Section |
20070207 | ASV | Implemented the resolution for issue
|
20070222 | ASV | Applied a |
20070315 | PY | Implemented the resolution for issue
|
20070316 | PY | Implemented part of the resolution as it applies to the Attachment spec, for issue
|
20070321 | ASV | Reset Section |