(07)
(08)
5. WS-Policy Attachment for WSDL 2.0
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.
2.2 XML Namespaces lists all the XML Namespaces that are used in this section.
(XML elements without a namespace prefix are from the Web Services Policy XML
Namespace.)
5.1 Example
The example below illustrates the use of WS-Policy Attachment for WSDL 2.0:
Example 5-1. Example Policy Attached to WSDL 2.0
(01)
(02) …
(03)
(04)
(05)
(06)
(07)
(08)
(09) …
(10) …
(11)
(12)
(13)
(15)
(16) …
(17) …
(18)
(19)
(21)
(23)
(24) …
(25)
(26)
(27) …
(28)
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 policy
expression that requires the use of either transport-level or message-level
security is attached to the binding description. The policy expression applies
to any message exchange associated with any 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 [MTOM]), a policy expression that represents
the addressing requirement and optimization capability is attached to the
endpoint description. The policy expression applies to any message exchange
associated with the RealTimeDataPort endpoint.
In the above example, the #secure and #common policy expressions attached to
the 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 policies,
that is, the effective policy for the RealTimeDataPort endpoint.
Example 5-2. Effective Policy for the RealTimeDataPort endpoint
(01)
(02)
(03)
(04)
(05)
(06)
(07)
(08)
(09) …
(10) …
(11)
(12)
(13)
(14)
5.2 Attaching Policy Expressions
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 MAY have one or more wsp:Policy or wsp:PolicyReference
child elements.
Policy attachment points in a WSDL document are associated with specific policy
subjects as described in the table below. There are four policy subjects in
WSDL: the service policy subject, the endpoint policy subject, the operation
policy subject and the message policy subject. When a policy expression is
attached to a policy subject in a WSDL document, capabilities and requirements
represented by the policy expression apply to any message exchange or message
associated with (or described by) the policy subject.
Table 5-1. Association of Policy Attachment Points with Policy Subjects
┌─────────────────────────┬────────────────────────────────┬──────────────────┐
│ Policy Attachment Point │ WSDL Component │ Policy Subject │
│ in a WSDL document │ │ │
├─────────────────────────┼────────────────────────────────┼──────────────────┤
│ wsdl20:service │ Service │ Service │
├─────────────────────────┼────────────────────────────────┼──────────────────┤
│ wsdl20:endpoint │ Endpoint │ │
├─────────────────────────┼────────────────────────────────┤ │
│ wsdl20:binding │ Binding │ Endpoint │
├─────────────────────────┼────────────────────────────────┤ │
│ wsdl20:interface │ Interface │ │
├─────────────────────────┼────────────────────────────────┼──────────────────┤
│ wsdl20:binding/ │ Binding Operation │ │
│ wsdl20:operation │ │ │
├─────────────────────────┼────────────────────────────────┤Operation │
│ wsdl20:interface/ │ Interface Operation │ │
│ wsdl20:operation │ │ │
├─────────────────────────┼────────────────────────────────┼──────────────────┤
│ wsdl20:binding/ │ │ │
│ wsdl20:operation/ │ Binding Message Reference │ │
│ wsdl20:input │ │ Message for an │
├─────────────────────────┼────────────────────────────────┤input message │
│ wsdl20:interface/ │ Interface Message Reference │ │
│ wsdl20:operation/ │ whose {direction} property is │ │
│ wsdl20:input │ ‘in’ │ │
├─────────────────────────┼────────────────────────────────┼──────────────────┤
│ wsdl20:binding/ │ │ │
│ wsdl20:operation/ │ Binding Message Reference │ │
│ wsdl20:output │ │ Message for an │
├─────────────────────────┼────────────────────────────────┤output message │
│ wsdl20:interface/ │ Interface Message Reference │ │
│ wsdl20:operation/ │ whose {direction} property is │ │
│ wsdl20:output │ ‘out’ │ │
├─────────────────────────┼────────────────────────────────┼──────────────────┤
│ wsdl20:binding/ │ Binding Fault │ │
│ wsdl20:fault │ │ │
├─────────────────────────┼────────────────────────────────┤ │
│ wsdl20:binding/ │ │ │
│ wsdl20:operation/ │ Binding Fault Reference │ │
│ wsdl20:infault │ │ Message for an │
├─────────────────────────┼────────────────────────────────┤input fault │
│ wsdl20:interface/ │ Interface Fault │ message │
│ wsdl20:fault │ │ │
├─────────────────────────┼────────────────────────────────┤ │
│ wsdl20:interface/ │ Interface Fault Reference │ │
│ wsdl20:operation/ │ whose {direction} property is │ │
│ wsdl20:infault │ ‘in’ │ │
├─────────────────────────┼────────────────────────────────┼──────────────────┤
│ wsdl20:binding/ │ Binding Fault │ │
│ wsdl20:fault │ │ │
├─────────────────────────┼────────────────────────────────┤ │
│ wsdl20:binding/ │ │ │
│ wsdl20:operation/ │ Binding Fault Reference │ │
│ wsdl20:outfault │ │ Message for an │
├─────────────────────────┼────────────────────────────────┤output fault │
│ wsdl20:interface/ │ Interface Fault │ message │
│ wsdl20:fault │ │ │
├─────────────────────────┼────────────────────────────────┤ │
│ wsdl20:interface/ │ Interface Fault Reference │ │
│ wsdl20:operation/ │ whose {direction} property is │ │
│ wsdl20:outfault │ ‘out’ │ │
└─────────────────────────┴────────────────────────────────┴──────────────────┘
For a WSDL component, the attached policy (extension to the WSDL component
model is described in 5.3 Extension to WSDL Component Model) is considered an
intrinsic part of the WSDL component definition and applies to all uses of that
definition. For example, when attached to a WSDL Interface component,
capabilities and requirements represented by a policy apply to all the use of
this WSDL Interface description. When attached to a WSDL Binding component,
capabilities and requirements represented by a policy apply to all the
Endpoints that support this binding description.
A policy associated with a service policy subject applies to any message
exchange (that is explicitly described by the Interface component in the
Service component's {interface} property) using any of the endpoints offered by
that service.
Policies associated with an endpoint policy subject apply to any message
exchange (that is explicitly described by the Interface component in the
Service component’s {interface} property of the Endpoint component’s {parent}
property) made using that endpoint. Given that a WSDL Interface component may
be used by one or more binding descriptions, it is RECOMMENDED that only a
policy containing policy assertions that apply to any possible binding
description should be attached.
Policies associated with an operation policy subject apply to the message
exchange described by that operation. Given that a WSDL Interface Operation
component may be used by one or more binding descriptions, it is RECOMMENDED
that only a policy containing policy assertions that apply to any possible
binding description should be attached.
Policies associated with a message policy subject apply to that message (input,
output or fault). Given that a WSDL Interface Message Reference, Interface
Fault, Interface Fault Reference components may be used by one or more binding
descriptions, it is RECOMMENDED that only a policy containing policy assertions
that apply to any possible binding should be attached.
Policies MAY be attached at different levels of the WSDL component hierarchy. A
message exchange with an endpoint MAY be described by the policies in all four
policy subjects simultaneously.
The common mechanism of associating a policy expression with a policy subject
is to attach a reference to the policy expression to the policy subject. As
described in the WS-Policy specification [Web Services Policy Framework], a
reference to a policy expression is represented using the 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.
Policy expressions can be included within a WSDL document or may reside
external to a WSDL document. If including policy expressions with a WSDL
document is the chosen approach, it is RECOMMENDED that the 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 policy expression attached to a policy
attachment point in a WSDL document, the expression MUST be marked as required
using the @wsdl20:required flag.
If the wsp:Policy elements are included as children of the wsdl20:description
element, these Policy elements MUST NOT be marked as required using the
@wsdl20:required. (Note: these policy expressions may be included as children
of the wsdl20:description element and may not be attached to any policy
attachment point in a WSDL document.)
5.3 Extension to WSDL Component Model
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 policy. The value of the {policy} property is a policy as
defined by Section 3 - Policy Model in the WS-Policy specification [Web
Services Policy Framework]. The following table describes the mapping from XML
representation to the {policy} property.
Table 5-2. Mapping from XML representation to the {policy} property
┌────────────┬────────────────────────────────────────────────────────────────┐
│ Component │ Value │
├────────────┼────────────────────────────────────────────────────────────────┤
│ │ A policy corresponding to the merge of wsp:Policy or │
│ Service │ wsp:PolicyReference elements, if any, in the [children] of the │
│ │ wsdl20:service element. │
├────────────┼────────────────────────────────────────────────────────────────┤
│ │ A policy corresponding to the merge of wsp:Policy or │
│ Endpoint │ wsp:PolicyReference elements, if any, in the [children] of the │
│ │ wsdl20:endpoint element. │
├────────────┼────────────────────────────────────────────────────────────────┤
│ │ A policy corresponding to the merge of wsp:Policy or │
│ Binding │ wsp:PolicyReference elements, if any, in the [children] of the │
│ │ wsdl20:binding element. │
├────────────┼────────────────────────────────────────────────────────────────┤
│ Binding │ A policy corresponding to the merge of wsp:Policy or │
│ Operation │ wsp:PolicyReference elements, if any, in the [children] of the │
│ │ wsdl20:binding/wsdl20:operation element. │
├────────────┼────────────────────────────────────────────────────────────────┤
│ Binding │ A policy corresponding to the merge of wsp:Policy or │
│ Fault │ wsp:PolicyReference elements, if any, in the [children] of the │
│ │ wsdl20:binding/wsdl20:fault element. │
├────────────┼────────────────────────────────────────────────────────────────┤
│ Binding │ A policy corresponding to the merge of wsp:Policy or │
│ Message │ wsp:PolicyReference elements, if any, in the [children] of the │
│ Reference │ wsdl20:binding/wsdl20:operation/wsdl20:input or wsdl20:binding │
│ │ /wsdl20:operation/wsdl20:output element. │
├────────────┼────────────────────────────────────────────────────────────────┤
│ Binding │ A policy corresponding to the merge of wsp:Policy or │
│ Fault │ wsp:PolicyReference elements, if any, in the [children] of the │
│ Reference │ wsdl20:binding/wsdl20:operation/wsdl20:infault or │
│ │ wsdl20:binding/wsdl20:operation/wsdl20:outfault element. │
├────────────┼────────────────────────────────────────────────────────────────┤
│ │ A policy corresponding to the merge of wsp:Policy or │
│ Interface │ wsp:PolicyReference elements, if any, in the [children] of the │
│ │ wsdl20:interface element. │
├────────────┼────────────────────────────────────────────────────────────────┤
│ Interface │ A policy corresponding to the merge of wsp:Policy or │
│ Operation │ wsp:PolicyReference elements, if any, in the [children] of the │
│ │ wsdl20:interface/wsdl20:operation element, if any. │
├────────────┼────────────────────────────────────────────────────────────────┤
│ Interface │ A policy corresponding to the merge of wsp:Policy or │
│ Fault │ wsp:PolicyReference elements, if any, in the [children] of the │
│ │ wsdl20:interface/wsdl20:fault element. │
├────────────┼────────────────────────────────────────────────────────────────┤
│ Interface │ A policy corresponding to the merge of wsp:Policy or │
│ Message │ wsp:PolicyReference elements, if any, in the [children] of the │
│ Reference │ wsdl20:interface/wsdl20:operation/wsdl20:input or │
│ │ wsdl20:interface/wsdl20:operation/wsdl20:output element. │
├────────────┼────────────────────────────────────────────────────────────────┤
│ Interface │ A policy corresponding to the merge of wsp:Policy or │
│ Fault │ wsp:PolicyReference elements, if any, in the [children] of the │
│ Reference │ 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 policy alternatives, and each policy alternative in
the first policy is equivalent to some policy alternative in the second policy,
and conversely.
Two policy alternatives are equivalent when each policy assertion in the first
policy alternative is equivalent to some policy assertion in the second policy
alternative, and conversely. If either policy alternative contains multiple
policy assertions of the same type, policy alternative equality is dependent on
the semantics of that assertion type.
Two policy assertions are equivalent if they have the same QName, if either
policy assertion is an ignorable policy assertion, both assertions must be
ignorable policy assertions and, if either policy assertion has a nested
policy, both assertions must have a nested policy and the nested policies must
be equal. If either assertion contains policy assertion parameters, then the
policy assertion parameters SHOULD be compared for equality. Comparing policy
assertion parameters for equality is not defined by this document, but policy
assertion equality may be further refined by the corresponding policy assertion
specification.
5.4 Effective Policy
The following diagram illustrates the four policy subjects in WSDL and how the
effective policy is calculated for each of these policy subjects.
Policy Subjects and Effective Policy in WSDL 2.0
Figure 5-1. Policy Subjects and Effective Policy in WSDL 2.0
If multiple policies are attached to WSDL components that collectively
represent a policy subject then the effective policy of these policies applies.
(For example, there is a policy attached to an Endpoint component that
describes the component and there is a policy attached to the Binding component
in the Endpoint component’s {binding} property.) The effective policy is the
merge of the policies that are attached to the same policy subject. The rest of
this section describes how the effective policy is calculated for each of these
policy subjects.
5.4.1 Service Policy Subject
The effective policy of a service policy subject is the policy in the {policy}
property of a Service component that describes the service.
5.4.2 Endpoint Policy Subject
The effective policy of an endpoint policy subject is the merge of policies in
the {policy} properties of:
• 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.
5.4.3 Operation Policy Subject
If the Binding component has an Interface component in the {interface}
property, then the effective policy of an operation policy subject MAY be
calculated by merging the policies in the {policy} properties of:
• 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 effective policy of an operation policy subject
MUST be calculated in relation to a specific endpoint, and is the policy in the
{policy} property of the Interface Operation component that describes the
operation.
5.4.4 Message Policy Subject (input message)
If the Binding component has an Interface component in the {interface}
property, then the effective policy of an input message MAY be calculated by
merging the policies in the {policy} properties of:
• 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 effective policy of an input message MUST be
calculated in relation to a specific endpoint, and is the policy in the
{policy} property of the Interface Message Reference component that describes
the input message.
5.4.5 Message Policy Subject (output message)
If the Binding component has an Interface component in the {interface}
property, then the effective policy of an output message MAY be calculated by
merging the policies in the {policy} properties of:
• 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 MUST be
calculated in relation to a specific endpoint, and is the policy in the
{policy} property of the Interface Message Reference component that describes
the output message.
5.4.6 Message Policy Subject (input fault message)
If the Binding component has an Interface component in the {interface}
property, then the effective policy of an input fault message MAY be calculated
by merging the policies in the {policy} properties of:
• 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 effective policy of an input fault message MUST
be calculated in relation to a specific endpoint, and is the merge of policies
in the {policy} properties of:
• 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.
5.4.7 Message Policy Subject (output fault message)
If the Binding component has an Interface component in the {interface}
property, then the effective policy of an output fault message MAY be
calculated by merging the policies in the {policy} properties of:
• 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 effective policy of an output fault message MUST
be calculated in relation to a specific endpoint, and is the merge of policies
in the {policy} properties of:
• 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.
6. Attaching Policies Using UDDI
This section defines a mechanism for associating policies with policy subjects
through the use of UDDI. It defines a minimum level of support for associating
policy expressions with entities in a UDDI registry. The calculation of
effective policy for UDDI entities is described in Section 6.1 Calculating
Effective Policy and Element Policy in UDDI. While the general concept for
associating policy expressions with UDDI entities, which is specified in
Sections 6.2 Referencing Remote Policy Expressions and 6.3 Registering Reusable
Policy Expressions, is based on UDDI Version 2 [UDDI API 2.0, UDDI Data
Structure 2.0], the necessary changes with respect to UDDI Version 3 [UDDI 3.0]
are explained in Section 6.4 Registering Policies in UDDI Version 3.
There are essentially two approaches for registering policies in UDDI. One
approach is to directly reference remotely accessible policy expressions in
UDDI entities, the other is to register policy expressions as distinct tModels
and then reference these tModels in each UDDI entity that is using the policy
expression. While the former approach (see Section 6.2 Referencing Remote
Policy Expressions) is expected to be used for policy expressions that are
mainly unique for a given Web service, the latter approach (see Section 6.3
Registering Reusable Policy Expressions) is expected to be used for more
modular and reusable policy expressions.
6.1 Calculating Effective Policy and Element Policy in UDDI
When attaching a policy to a UDDI entity a policy scope is implied for that
attachment. The policy scope only contains the policy subjects associated with
that entity, and not those associated with the children of that entity. This
policy is the entity's element policy.
Each policy assertion contained within a UDDI entity's element policy should
have the correct semantic such that the policy subject for that assertion is
that UDDI entity. For example, assertions that describe behaviours regarding a
service provider should only be contained within policies attached to a
businessEntity structure.
For UDDI tModels that represent Web service types, the element policy is
considered an intrinsic part of the tModel and applies to all uses of that
tModel. In particular, it MUST be merged into the effective policy of every
bindingTemplate that references that tModel.
Policies that apply to deployed Web services (bindingTemplates) are only
considered in the effective policy of that deployed resource itself.
Each of these entities MAY have an element policy per Section 3. Policy
Attachment. The remainder of this section defines how that element policy is
interpreted to calculate the effective policy.
6.1.1 Service Provider Policy Subject
The following UDDI element is considered as the service provider policy
subject:
• uddi:businessEntity
This element MAY have element policy as per Section 3. Policy Attachment, and
if present MUST be merged into the effective policy of the UDDI businessEntity
Subject.
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.
6.1.2 Service Policy Subject
The following UDDI element is considered as the service policy subject:
• uddi:businessService
This element MAY have element policy as per Section 3. Policy Attachment, and
if present MUST be merged into the effective policy of the UDDI businessService
Subject.
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.
6.1.3 Endpoint Policy Subject
The following UDDI elements collectively describe an endpoint:
• uddi:bindingTemplate
• uddi:tModel
These elements MAY have element policy as per Section 3. Policy Attachment. The
policy scope implied by each of these elements contains the endpoint policy
subject representing the deployed endpoint.
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 effective policy for a UDDI endpoint includes the element policy of the
uddi:bindingTemplate element that defines the endpoint merged with the element
policy of those uddi:tModel elements that are referenced in contained
uddi:tModelInstanceInfo elements.
6.2 Referencing Remote Policy Expressions
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 policy
with an entity in a UDDI registry.
This new tModel is called the remote policy reference category system and is
defined in Appendix B.1 Remote Policy Reference Category System.
UDDI registries MUST use the (UDDI V2 [UDDI Data Structure 2.0]) tModelKey
uuid:a27078e4-fd38-320a-806f-6749e84f8005 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 policy
expressions; that is, when referencing this category system in a categoryBag,
the corresponding keyValue of the keyedReference is the IRI of the policy
expression.
Using the remote policy reference category system, one can then associate a
policy expression with a businessEntity, a businessService, and a tModel using
the entity's categoryBag. For example, associating the policy expression that
is identified by the IRI http://www.example.com/myservice/policy with a
businessService is done as follows:
(01)
(02) …
(03) …
(04) …
(05)
(06)
(10)
(11)
The tModelKey of the keyedReference MUST match the fixed tModelKey from the
remote policy reference category system. The keyValue MUST be the IRI that
identifies the policy expression.
A different approach has to be taken to associate a policy expression with a
bindingTemplate, since bindingTemplates do not contain a categoryBag in UDDI
Version 2. Therefore, the bindingTemplate's tModelInstanceInfo and
instanceParms MUST be used as follows:
(01)
(02) …
(03)
(04)
(06)
(07)
(08) http://www.example.com/myservice/policy
(09)
(10)
(11)
(12)
(13)
The tModelKey of the tModelInstanceInfo MUST match the fixed tModelKey from the
remote policy reference category system as defined above. The instanceParms
MUST be the IRI that identifies the policy expression.
6.3 Registering Reusable Policy Expressions
In addition to using the approach outlined in the section above, publishers may
register a specific policy expression in a UDDI registry as a distinct tModel.
To properly categorize tModels as policy expressions, Web Services Policy 1.5 -
Attachment pre-defines the Web Services Policy Types category system as a
tModel. This tModel is defined in Appendix B.2 Web Services Policy Types
Category System.
The following illustrates a tModel for the policy expression identified by the
IRI http://www.example.com/myservice/policy.
(01)
(02) …
(03)
(04) Policy Expression for example's Web services
(05)
(06)
(07) Web Services Policy Expression
(08) http://www.example.com/myservice/policy
(09)
(10)
(11)
(15)
(19)
(20)
The first keyedReference specifies that the tModel represents a policy
expression — rather than only being associated with one — by using the Web
Services Policy Types category system's built-in category "policy", which is
its single valid value. This is necessary in order to enable UDDI inquiries for
policy expressions in general. The second keyedReference designates the policy
expression the tModel represents by using the approach from the section above.
This is necessary in order to enable UDDI inquiries for particular policy
expressions based on their IRI.
Note that the policy expression IRI is also specified in the tModel's overview
URL to indicate that it is a resolvable URL to actually retrieve the policy
expression.
Web Services Policy 1.5 - Attachment pre-defines another tModel that is used to
associate such a pre-registered, locally available policy expressions with an
entity in a UDDI registry
This new tModel is called the local policy reference category system and is
defined in Appendix B.3 Local Policy Reference Category System.
UDDI registries MUST use the tModelKey
uuid:a27f7d45-ec90-31f7-a655-efe91433527c 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 keyValue of the keyedReference is the tModelKey of the tModel
that represents the policy expression.
Given the local policy reference category system, one can then associate a
policy expression tModel with a businessEntity, a businessService, and a tModel
using the entity's categoryBag. For example, associating the policy expression
tModel with the tModelKey "uuid:04cfa…" from above with a businessService is
done as follows:
(01)
(02) …
(03) …
(04) …
(05)
(06)
(10)
(11)
The tModelKey of the keyedReference MUST match the fixed tModelKey from the
local policy reference category system. The keyValue MUST be the tModelKey of
the policy expression that is registered with the UDDI registry.
A different approach has to be taken to associate a policy expression with a
bindingTemplate, since bindingTemplates do not contain a categoryBag in UDDI
Version 2. Therefore, the bindingTemplate's tModelInstanceInfo and
instanceParms MUST be used as follows:
(01)
(02) …
(03)
(04)
(06)
(07) uuid:04cfa…
(08)
(09)
(10)
(11)
The tModelKey of the tModelInstanceInfo MUST match the fixed tModelKey from the
local policy reference category system. The instanceParms MUST be the tModelKey
of the policy expression that is registered with the UDDI registry.
6.4 Registering Policies in UDDI Version 3
UDDI Version 3 [UDDI 3.0] provides a number of enhancements in the areas of
modeling and entity keying. Special considerations for UDDI multi-version
support are outlined in chapter 10 of [UDDI 3.0]. The changes with respect to
the previous sections are as follows.
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 tModelKey for the remote policy reference tModel changes from
"uuid:a27078e4-fd38-320a-806f-6749e84f8005" to
"uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03".
The tModelKey for the Web Services Policy Types tModel changes from
"uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993" to
"uddi:schemas.xmlsoap.org:policytypes:2003_03".
The tModelKey for the local policy reference tModel changes from
"uuid:a27f7d45-ec90-31f7-a655-efe91433527c" to
"uddi:schemas.xmlsoap.org:localpolicyreference:2003_03".
Second, rather than putting policy expression references in a bindingTemplate's
tModelInstanceInfo, they are added to the bindingTemplate's categoryBag,
analogous to the mechanism described for other UDDI entities. For example, the
example bindingTemplate from section 6.1 Calculating Effective Policy and
Element Policy in UDDI would be changed as follows:
(01)
(02) …
(03) …
(04)
(05)
(10)
(11)
Third, inquiries for reusable policy expression tModels described in Section
6.3 Registering Reusable Policy Expressions and UDDI tModel entities that are
associated with remote policy expression is enhanced by the wildcard mechanism
for keyValues in keyedReferences. For example, searching for all policy
expression tModels whose IRI starts with http://www.example.com/, the following
find_tModel API call can be used:
(01)
(02)
(03)
(07)
(08)
(09) approximateMatch
(10)
(11)
Fourth, all UDDI entities may be digitally signed using XML digital signatures
[XML-Signature]. Publishers who want to digitally sign their policy expression
tModels or policy expression references in UDDI MUST use the Schema-centric
canonicalization algorithm [SCC14N].
7. Security Considerations
It is RECOMMENDED that policy attachments be integrity protected to permit the
detection of tampering. This can be done using a technology such as XML DSig [
XML-Signature], SSL/TLS [IETF RFC 2246], or WS-Security 2004 [WS-Security 2004
]. This also provides a mechanism for authenticating policy attachments by
determining if the signer has the right to "speak for" the scope of the policy
attachment.
Policies SHOULD NOT be accepted unless they are signed and have an associated
security token to specify the signer has the right to "speak for" the scope
containing the policy.
A more complete discussion of security considerations can be found in the
Security Considerations section of the Web Services Policy 1.5 - Framework
document [Web Services Policy Framework].
8. Conformance
8.1 External Policy Attachment Conformance
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 [XML Schema Structures
] for that element as defined by this specification (http://www.w3.org/2007/02/
ws-policy.xsd) and additionally adheres to all the constraints contained in
Section 3.4 External Policy Attachment of this specification. Such a conformant
element information item constitutes an external policy attachment.
8.2 WSDL 1.1 Attachment Conformance
A WSDL 1.1 [WSDL 1.1] description conforms to this specification when it
incorporates one or more element policies and additionally adheres to all the
constraints contained in section 4. Attaching Policies Using WSDL 1.1
8.3 WSDL 2.0 Attachment Conformance
A WSDL 2.0 [WSDL 2.0 Core Language] description conforms to this specification
when it incorporates one or more element policies and additionally adheres to
all the constraints contained in section 5. WS-Policy Attachment for WSDL 2.0
A. References
A.1 Normative References
[BP 1.1]
Basic Profile Version 1.1, K. Ballinger, et al, Editors. The Web
Services-Interoperability Organization, 10 June 2006. This version of the
Basic Profile Version 1.1 is http://www.ws-i.org/Profiles/
BasicProfile-1.1-2006-04-10.html. The latest version of the Basic Profile
Version 1.1 is available at http://www.ws-i.org/Profiles/
BasicProfile-1.1.html
[IETF RFC 3023]
IETF "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D. Kohn, July
1998. (See http://www.ietf.org/rfc/rfc3023.txt.)
[IETF RFC 2119]
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,
Author. Internet Engineering Task Force, June 1999. Available at http://
www.ietf.org/rfc/rfc2119.txt.
[IETF RFC 3986]
Uniform Resource Identifier (URI): Generic Syntax , T. Berners-Lee, R.
Fielding and L. Masinter, Authors. Network Working Group, January 2005.
Available at http://www.ietf.org/rfc/rfc3986.txt.
[IETF RFC 3987]
Internationalized Resource Identifiers (IRIs) , M. Duerst and M. Suignard,
Authors. Internet Engineering Task Force, January 2005. Available at http:/
/www.ietf.org/rfc/rfc3987.txt.
[UDDI API 2.0]
UDDI Version 2.04 API, T. Bellwood, Editor. Organization for the
Advancement of Structured Information Standards, 19 July 2002. This version
of UDDI Version 2.0 API is http://uddi.org/pubs/
ProgrammersAPI-V2.04-Published-20020719.htm. The latest version of the UDDI
2.0 API is available at http://uddi.org/pubs/ProgrammersAPI_v2.htm.
[UDDI Data Structure 2.0]
UDDI Version 2.03 Data Structure Reference, C. von Riegen, Editor.
Organization for the Advancement of Structured Information Standards, 19
July 2002. This version of UDDI Version 2.0 Data Structures is http://
uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm. The latest
version of the UDDI 2.0 Data Structures is available at http://uddi.org/
pubs/DataStructure_v2.htm.
[UDDI 3.0]
UDDI Version 3.0.1, L. Clément, et al, Editors. Organization for the
Advancement of Structured Information Standards, 14 October 2003. This
version of the UDDI Version 3.0 is http://uddi.org/pubs/
uddi-v3.0.1-20031014.htm. The latest version of the UDDI 3.0 specification
is available at http://uddi.org/pubs/uddi_v3.htm.
[Web Services Policy Framework]
Web Services Policy 1.5 - Framework, A. S. Vedamuthu, D. Orchard, F.
Hirsch, M. Hondo, P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World
Wide Web Consortium, 28, February 2007. This version of the specification
of the Web Services Policy 1.5 - Framework specification is http://
www.w3.org/TR/2007/CR-ws-policy-20070228. The latest version of Web
Services Policy 1.5 - Framework is available at http://www.w3.org/TR/
ws-policy.
[WS-Addressing Core]
Web Services Addressing 1.0 - Core, M. Gudgin, M. Hadley, and T. Rogers,
Editors. World Wide Web Consortium, 9 May 2006. This version of the Web
Services Addressing 1.0 - Core Recommendation is http://www.w3.org/TR/2006/
REC-ws-addr-core-20060509/. The latest version of Web Services Addressing
1.0 - Core is available at http://www.w3.org/TR/ws-addr-core.
[WSDL 1.1]
Web Services Description Language (WSDL) 1.1, E. Christensen, et al,
Authors. World Wide Web Consortium, March 2001. Available at http://
www.w3.org/TR/2001/NOTE-wsdl-20010315.
[WSDL 2.0 Core Language]
Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language,
R. Chinnici, J. J. Moreau, A. Ryman, S. Weerawarana, Editors. World Wide
Web Consortium, 27 March 2006. This version of the WSDL 2.0 specification
is http://www.w3.org/TR/2006/CR-wsdl20-20060327. The latest version of WSDL
2.0 is available at http://www.w3.org/TR/wsdl20.
[WS-Security 2004]
Web Services Security: SOAP Message Security 1.0 (WS-Security 2004), A.
Nadalin, C. Kaler, P. Hallam-Baker, and R. Monzillo, Editors. Organization
for the Advancement of Structured Information Standards, March 2004.
Available at http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-soap-message-security-1.0.pdf.
[XML BASE]
XML Base, Jonathan Marsh, Editor. World Wide Web Consortium, 27 June 2001.
This version of the XML Base Recommendation is http://www.w3.org/TR/2001/
REC-xmlbase-20010627/. The latest version of XML Base is available at http:
//www.w3.org/TR/xmlbase/.
[XML Information Set]
XML Information Set (Second Edition), J. Cowan and R. Tobin, Editors. World
Wide Web Consortium, 24 October 2001, revised 4 February 2004. This version
of the XML Information Set Recommendation is http://www.w3.org/TR/2004/
REC-xml-infoset-20040204. The latest version of XML Information Set is
available at http://www.w3.org/TR/xml-infoset.
[XML Namespaces]
Namespaces in XML 1.0 (Second Edition), T. Bray, D. Hollander, A. Layman,
and R. Tobin, Editors. World Wide Web Consortium, 14 January 1999, revised
16 August 2006. This version of the XML Information Set Recommendation is
http://www.w3.org/TR/2006/REC-xml-names-20060816/. The latest version of
Namespaces in XML is available at http://www.w3.org/TR/REC-xml-names.
[XML Schema Datatypes]
XML Schema Part 2: Datatypes Second Edition, P. Byron and A. Malhotra,
Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004.
This version of the XML Schema Part 2 Recommendation is http://www.w3.org/
TR/2004/REC-xmlschema-2-20041028. The latest version of XML Schema Part 2
is available at http://www.w3.org/TR/xmlschema-2.
[XML Schema Structures]
XML Schema Part 1: Structures Second Edition, H. Thompson, D. Beech, M.
Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 2 May 2001,
revised 28 October 2004. This version of the XML Schema Part 1
Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The
latest version of XML Schema Part 1 is available at http://www.w3.org/TR/
xmlschema-1.
A.2 Other References
[IETF RFC 2246]
IETF "RFC 2246: The TLS Protocol", T. Dierks, C. Allen, January 1999. (See
http://www.ietf.org/rfc/rfc2246.txt.)
[WSDL11 ElementIds]
WSDL 1.1 Element Identifiers D. Orchard, Editor. World Wide Web Consortium,
15 November 2006. TBD: URI
[MTOM]
SOAP Message Transmission Optimization Mechanism, M. Gudgin, N. Mendelsohn,
M. Nottingham and H. Ruellan, Editors. World Wide Web Consortium, 25
January 2005. This version of the SOAP Message Transmission Optimization
Mechanism Recommendation is http://www.w3.org/TR/2005/
REC-soap12-mtom-20050125/. The latest version of SOAP Message Transmission
Optimization Mechanism is available at http://www.w3.org/TR/soap12-mtom/.
[WS-MTOMPolicy]
MTOM Serialization Policy Assertion (WS-MTOMPolicy), C. Ferris, et al,
Authors. International Business Machines Corporation and Microsoft
Corporation, Inc., September 2006. Available at http://schemas.xmlsoap.org/
ws/2004/09/policy/optimizedmimeserialization/
[SCC14N]
Schema Centric XML Canonicalization Version 1.0, S. Aissi, A. Hately, and
M. Hondo, Editors. Organization for the Advancement of Structured
Information Standards, 23 May 2005. This version of the Schema Centric XML
Canonicalization Version 1.0 is http://uddi.org/pubs/
SchemaCentricCanonicalization-20050523.htm. The latest version of Schema
Centric XML Canonicalization Version 1.0 is available at http://uddi.org/
pubs/SchemaCentricCanonicalization.htm.
[WS-Addressing Policy]
Web Services Addressing 1.0 - WSDL Binding, M. Gudgin, M. Hadley, T. Rogers
and Ü. Yalçinalp, Editors. World Wide Web Consortium, 29 May 2006. This
version of the Web Services Addressing 1.0 - WSDL Binding is http://
www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/. The latest version of Web
Services Addressing 1.0 - WSDL Binding is available at http://www.w3.org/TR
/ws-addr-wsdl.
[WS-MetadataExchange]
Web Services Metadata Exchange (WS-MetadataExchange), K. Ballinger, et al,
Authors. BEA Systems Inc., Computer Associates International, Inc.,
International Business Machines Corporation, Microsoft Corporation, Inc.,
SAP AG, Sun Microsystems, and webMethods, August 2006. Available at http://
schemas.xmlsoap.org/ws/2004/09/mex/
[WS-RM Policy]
Web Services Reliable Messaging Policy Assertion (WS-RM Policy), D. David,
A. Kamarkar, G. Pilz, and Ü. Yalçinalp, Editors. Organization for the
Advancement of Structured Information Standards, 24 April 2006. Available
at http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html
[WS-SecurityPolicy]
WS-SecurityPolicy v1.0, A. Nadalin, M. Gudgin, A. Barbir, and H. Granqvist,
Editors. Organization for the Advancement of Structured Information
Standards, 8 December 2005. Available at http://www.oasis-open.org/
committees/download.php/15979/oasis-wssx-ws-securitypolicy-1.0.pdf.
[WSDL 1.1 Binding for SOAP 1.2]
WSDL 1.1 Binding for SOAP 1.2, D. Angelov, et al, Authors. World Wide Web
Consortium, 5 April 2006. Available at http://www.w3.org/Submission/2006/
SUBM-wsdl11soap12-20060405/.
[XML-Signature]
XML-Signature Syntax and Processing, D. Eastlake, J. Reagle, and D. Solo,
Editors. The Internet Society & World Wide Web Consortium, 12 February
2002. This version of the XML-Signature Syntax and Processing
Recommendation is http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/. The
latest version of XML-Signature Syntax and Processing is available at http:
//www.w3.org/TR/xmldsig-core/.
[XOP]
XML-binary Optimized Packaging, M. Gudgin, N. Mendelsohn, M. Nottingham and
H. Ruellan, Editors. World Wide Web Consortium, 25 January 2005. This
version of the XML-binary Optimized Packaging Recommendation is http://
www.w3.org/TR/2005/REC-xop10-20050125/. The latest version of XML-binary
Optimized Packaging is available at http://www.w3.org/TR/xop10/.
[XPointer Framework]
XPointer Framework,Paul Grosso, Eve Maler, Jonathan Marsh, Norman Walsh,
Editors. World Wide Web Consortium, 22 November 2002. This version of the
XPointer Framework Proposed Recommendation is http://www.w3.org/TR/2003/
REC-xptr-framework-20030325/ The latest version of XPointer Framework is
available at http://www.w3.org/TR/xptr-framework/.
B. UDDI tModel Definitions
This section contains the UDDI tModel definitions for the canonical tModels
used in Section 6. Attaching Policies Using UDDI. The tModelKeys shown in the
tModel structure sections are valid UDDI Version 2 keys. When using UDDI
Version 3, the corresponding derived UDDI Version 2 keys must be used.
B.1 Remote Policy Reference Category System
B.1.1 Design Goals
This tModel is used to attach a policy to a UDDI entity by referencing the
policy's IRI.
B.1.2 tModel Definition
┌─────────────────┬───────────────────────────────────────────────────────────┐
│ Name: │ http://schemas.xmlsoap.org/ws/2003/03/ │
│ │ remotepolicyreference │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ │ Category system used for UDDI entities to point to an │
│ Description: │ 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:schemas.xmlsoap.org:remotepolicyreference:2003_03 │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ UDDI V1,V2 │ uuid:a27078e4-fd38-320a-806f-6749e84f8005 │
│ format key: │ │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ Categorization: │ categorization │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ Checked: │ No │
└─────────────────┴───────────────────────────────────────────────────────────┘
B.1.3 tModel Structure
(01)
(02) http://schemas.xmlsoap.org/ws/2003/03/remotepolicyreference
(03) Category system used for UDDI entities to point to an external
(04) Web Services Policy Attachment policy expression that describes their characteristics.
(05) See Web Services Policy 1.5 - Attachment specification for further details.
(06)
(07)
(11)
(12)
B.2 Web Services Policy Types Category System
B.2.1 Design Goals
This tModel is used to categorize tModels as representing policy expressions.
There is only one valid value, namely "policy", that indicates this very fact.
It is RECOMMENDED that tModels categorized as representing policy expressions
reference no more and no less than this very policy expression using the remote
policy reference category system.
B.2.2 tModel Definition
┌─────────────────┬───────────────────────────────────────────────────────────┐
│ Name: │ http://schemas.xmlsoap.org/ws/2003/03/policytypes │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ │ Web services policy types category system used for UDDI │
│ Description: │ tModels to characterize them as Web services policy–based │
│ │ policy expressions. │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ UDDI Key (V3): │ uddi:schemas.xmlsoap.org:policytypes:2003_03 │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ UDDI V1,V2 │ uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993 │
│ format key: │ │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ Categorization: │ categorization │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ Checked: │ No │
└─────────────────┴───────────────────────────────────────────────────────────┘
B.2.3 tModel Structure
(01)
(02) http://schemas.xmlsoap.org/ws/2003/03/policytypes
(03) Web Services Policy Types category system used for UDDI tModels
(04) to characterize them as Web Services Policy – based policy expressions.
(05)
(06)
(10)
(11)
B.3 Local Policy Reference Category System
B.3.1 Design Goals
This tModel is used to attach a policy expression to a UDDI entity by
referencing the UDDI entity that represents this policy expression. The local
policy reference category system is based on tModelKeys. It is expected that
referenced tModels are registered with the same UDDI registry and are
categorized as representing policy expressions using the Web services policy
types category system.
B.3.2 tModel Definition
┌─────────────────┬───────────────────────────────────────────────────────────┐
│ Name: │ http://schemas.xmlsoap.org/ws/2003/03/ │
│ │ localpolicyreference │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ │ Category system used for UDDI entities to point to a Web │
│ Description: │ services policy policy expression tModel that describes │
│ │ their characteristics. See Web Services Policy 1.5 - │
│ │ Attachment specification for further details. │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ UDDI Key (V3): │ uddi:schemas.xmlsoap.org:localpolicyreference:2003_03 │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ UDDI V1,V2 │ uuid:a27f7d45-ec90-31f7-a655-efe91433527c │
│ format key: │ │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ Categorization: │ categorization │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ Checked: │ Yes │
└─────────────────┴───────────────────────────────────────────────────────────┘
B.3.3 tModel Structure
(01)
(02) http://schemas.xmlsoap.org/ws/2003/03/localpolicyreference
(03) Category system used for UDDI entities to point to a
(04) Web Services Policy policy expression tModel that describes their characteristics.
(05) See Web Services Policy 1.5 - Attachment specification for further details.
(06)
(07)
(11)
(15)
(19)
(20)
C. Acknowledgements (Non-Normative)
This document is the work of the W3C Web Services Policy Working Group.
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: Jong Lee (BEA Systems, Inc.), Bijan
Parsia (University of Manchester), Seumas Soltysik (IONA Technologies, Inc.).
The people who have contributed to discussions on public-ws-policy@w3.org are
also gratefully acknowledged.
D. Changes in this Version of the Document (Non-Normative)
A list of major editorial changes since the Working Draft dated 17 November,
2006 is below:
• Clarified the relationship between URI domain expression and WSDL 1.1
Element Identifiers [WSDL11 ElementIds] in Section 3.4.1 URI Domain
Expression.
• Explicitly described the interaction between policy attachment mechanisms
and XML Base in Section 3.5 Use of IRIs in Policy Attachment.
E. Web Services Policy 1.5 - Attachment Change Log (Non-Normative)
┌─────────┬──────┬────────────────────────────────────────────────────────────┐
│ Date │Author│ Description │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060712 │ASV │Updated the list of editors. Completed action items 20 from │
│ │ │the Austin F2F. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060712 │DBO │Completed action item 12 │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│ │ │Completed action items Editors to remove extraneous │
│ │ │namespace decl in the example at the end of section 3.4 18, │
│20060718 │DBO │RFC2606 for domain names 09 (note: PLH had already done but │
│ │ │it didn't show up in the change log) editors to straighten │
│ │ │up Note after example 3-1 11 │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060719 │TIB │Completed action item 22: Linked SVG graphic │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060721 │ASV │Completed action items 23, 25 and 26 from the Austin F2F. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060721 │ASV │Completed action item 29 from the Austin F2F. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060726 │ASV │Incorporated the XML namespace URI versioning policy adopted│
│ │ │by the WG. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│ │ │Completed action items: 15 as early as possible in the doc, │
│20060808 │DBO │use the definition that are defined in the doc. Issue 3545, │
│ │ │use of {any} and {@any} in xpath-like expressions not │
│ │ │defined in Notational Conventions section │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060808 │ASV │Implemented the resolution for issue 3543. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060809 │DBO │Implemented the resolution for issue 3546: wsdl 2.0 status │
│ │ │mention. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060809 │ASV │Implemented the resolution for issue 3556 and the resolution│
│ │ │for issue 3558. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│ │ │Completed action items: 15 remove use if emph/ital terms. │
│20060811 │DBO │Framework: removed emph on conceptually replace and support;│
│ │ │attachment: make merge a termdef │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│ │ │Added a new Section D. Changes in this Version of the │
│20060813 │ASV │Document (that provides a list of substantive chanages since│
│ │ │the previous publication). │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060825 │PY │Implemented the resolution for issue 3544. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060827 │TIB │Completed action item: resolution for adding Conformance │
│ │ │section. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060827 │TIB │Implemented the resolution for issue 3605: typo in example. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060829 │ASV │Implemented the resolution for issue 3561: replaced URI with│
│ │ │IRI. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│ │ │Completed partial resolution for issue 3590. for adding │
│200609006│DBO │document attribute extensbility of wsp:Policy/@{any} and │
│ │ │wsp:Policy/.../wsp:PolicyReference/@{any}, specifically │
│ │ │making attribute extensibility for any namespace. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060906 │ASV │Implemented the resolution for issue 3557: clarify the use │
│ │ │of domain expressions. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20060924 │TIB │Implemented the resolution for issue 3709: Editorial │
│ │ │corrections from UDDI team. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│ │ │Created 5. WS-Policy Attachment for WSDL 2.0 per action item│
│20060925 │ASV │2 from the Bellevue F2F. This section is based on a │
│ │ │contribution from BEA, IBM, Microsoft and Oracle. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061002 │DBO │Implemented the http://www.w3.org/2005/06/tracker/wspolicy/ │
│ │ │actions/64 for issue 3559: Conformance Section. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│ │ │Implemented the resolution for issue 3712 │
│20061002 │DBO │:wsp:PolicyReference can be used in any place where you can │
│ │ │use wsp:Policy │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061008 │MH │Implemented the resolution for issue summary of Action 10 │
│ │ │from F2F replaced "subject" instances with "policy subject" │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061012 │PY │Updated "Changes in this Version" section (Appendix D) │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061019 │PY │Completed action item: 57 PaulC's comments. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│ │ │Changed the SVG link and re-formatted the examples in B. │
│20061027 │FS │UDDI tModel Definitions (these changes were necessary for │
│ │ │PDF creation). │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061030 │DBO │Implemented the resolution titled "Hyperlink terms such as │
│ │ │policy expression..." │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│ │ │Completed action item: 58 to add a pointer to the Security │
│20061031 │TIB │Considerations section of the framwork document. This is a │
│ │ │follow-up to closed issue 110 │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061102 │ASV │Implemented the resolution for Editors' Action 12. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061102 │ASV │Reset Section D. Changes in this Version of the Document. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061109 │PY │Implemented the resolution for Issue 3894. Editors' Action │
│ │ │71. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061109 │TIB │Implemented Editors' Action 74. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061109 │ASV │Implemented the resolution for issues 3721 and 3789. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061109 │ASV │Implemented the resolution for issues 3599 and 3730. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061109 │ASV │Updated Section D. Changes in this Version of the Document. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061127 │ASV │Added Frederick and Umit to the list of editors. Editors' │
│ │ │action 86. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20061218 │FJH │Implemented the resolution for issue 4039 to close editors' │
│ │ │action 99. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20070108 │ASV │Applied the missed amendment (re issue 4039) to section 3.5 │
│ │ │Use of IRIs in Policy Attachment. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20070108 │ASV │Reset Section D. Changes in this Version of the Document. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20070116 │DBO │Completed action item: 116 and 124 Resolution for issue 4211│
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│ │ │Applied the resolution for issues 4045 and 4127 using first │
│20070117 │FJH │and second parts as outlined in working group resolution. │
│ │ │This closes editors actions 139 and 111. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20070121 │MH │Completed action item: 129 Resolution for issue 4207 │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20070122 │ASV │Implemented the resolution for issue 4230. Editors' action │
│ │ │135. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20070122 │UY │Implemented the resolution for issue 4209. Editors' action │
│ │ │131. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20070122 │UY │Implemented the resolution for issue 4226. Editors' action │
│ │ │134. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20070123 │ASV │Applied missed items (re issue 4045) to section 3.4.1 URI │
│ │ │Domain Expression and 5. WS-Policy Attachment for WSDL 2.0. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│ │ │Applied a missed item (re issue 4226) to section 5. │
│20070123 │ASV │WS-Policy Attachment for WSDL 2.0: added wsp prefix to │
│ │ │Example 5-2 and all occurrences of Policy and │
│ │ │PolicyReference. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20070123 │ASV │Fixed a typo in A.2 Other References: "[IETF RFC 3023]IETF │
│ │ │"RFC 2246:". │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20070124 │ASV │Updated Section D. Changes in this Version of the Document. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20070207 │ASV │Implemented the resolution for issue 4306. Editors' action │
│ │ │158. │
├─────────┼──────┼────────────────────────────────────────────────────────────┤
│20070222 │ASV │Applied a missed item (re issue 4207) to 2.2 XML Namespaces.│
└─────────┴──────┴────────────────────────────────────────────────────────────┘