wsrmp nested policy assertions do contain elements from wsp namespace

["Tom Rutt" <tom@coastin.com>]

On an earlier email I stated that the wsp namespace is not used in the
schemas for wsrmp or wsmc specs.

On further investigation, I found the situation to be not so cut and dry.

This email does not make any recommended changes to our specs, but is
intended to add some facts to the current controversy under discussion in
the WS-RX TC.

WSMC does not define any assertions with nested policy.  So for wsmc,
an XML serialized value of the "MakeConnection" assertion will not contain
any elements from the wsp namespace.

The wsp namespace would be required for any policy expression which
contains an alternative with the MakeConnection assertion, but a wsp
namespace is not required to serialize the value of the  assertion, itself.
This may be a subtle point, but it is a valid distinction between
assertions which have nested policy and those which do not.

However, the wsmp spec does define several assertions which contain
nested policy expressions.

For example, the wsrmp:RMAssertion policy assertion type is defined as a
container for nested policy assertions. This means that an XML serialized
value of the RMAssertion assertion, itself, MUST contain the element
wsp:policy, which is used to convey the nested policy expression.
Any serialized XML value of these nested assertions MUST include a
namespace declaration
for some ws-policy namespace.

However, the schema for wsrmp uses an any type with namespace="##other" to
specify the
requirement for a contained wsp:policy element

 <xs:element name="RMAssertion">
     <xs:complexType>
         <xs:sequence>
             <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
     </xs:complexType>
 </xs:element>

So the reason the schema for wsrmp does not explicitly include a wsp
namespace is because of the use of a "loose typing trick", involving
xs:any, to get around documenting an explicit choice of a
ws-policy namespace. However, this "any" element must be resolved,
in any serialized value of the RMAssertion, to be a "policy"
element Qname from some ws-policy namespace.

The wsrmp spec should state that this contained element, specified as an
xs:any, must have the Qname wsp:policy, where "wsp" must be associated
with an explicit ws policy namespace version before the policy can be
serialized into XML.  I think that may be the historical reason for the
wording "Normative Outline" used in section 2.2 of the wsrmp spec, which
defines the wsrmp:RMAssertion policy assertion.  It might also be an
undocumented historical reason why
CD 7 and earlier versions of wsrmp placed ws-policy references as
normative, while CD7 and earlier versions of wsmc placed ws-policy
references as non-normative

I would summarize this discussion as follows: the CD7 (and earlier)
wsrm policy specs abstracted out the version of ws policy in the schema
by using "any" type to specify the nested policy expression value in
its definitions of nested policy assertion types.  However, even
though the schema for wsrm policy spec abstracted out the version of
ws-policy, CD07 and earlier versions of WSRM policy spec were tied to a
normative reference to an explicit ws-policy version.

As an aside, I would like to point out that ws addressing metadata spec
LC draft has also defined nested assertions, but in the schema it
actually specifies wsp:Policy as a nested element in their Schema,
using the explicit namespace                    
xmlns:wsp="http://www.w3.org/2006/07/ws-policy";  .

I do not recall that anybody has raised a concern that ws addressing
metadata spec has not abstracted itself away from a particular version of
WS-Policy.

Hope this helps, not hinders, the discussion to move forward.
-- 
Tom Rutt
Tel: +1 732 801 5744
Fax: +1 732 774 5133
email: tom@coastin.com; trutt@us.fujitsu.com