At 12:30 PM 2006-09-25, Daniel Roth wrote:

> And if I want to change the policy, and the new policy has a new URI,
> I would need to update links in both WSDL and the tModel.

You can solve this problem by having your policy references point to a URI that references the "current" policy. Section 4.3.4 of the Policy Framework states: "The IRI included in the retrieved policy expression, if any, MAY be different than the IRI used to retrieve the policy expression."

For example, you could have policy reference like this:

<wsp:PolicyReference URI="urn:currentPolicy" />

So @URI "identifies" the policy, so I could use a UDDI tModelKey as the identifier.

(Lets ignore for the moment that the "uddi" URI scheme is not registered with IANA).
http://xml.coverpages.org/draft-hately-uddi-uri-scheme-00.txt
http://lists.oasis-open.org/archives/uddi-spec/200408/msg00081.html

That points to a policy like this:

<wsp:Policy Name="urn:myUpdatedPolicy" >
...
</wsp:Policy>

How you resolve external policy references is implementation specific,

So there may be many ways to resolve the external policy reference.

I suggested one such way, that is,

In WSDL use <wsp:PolicyReference URI="uddi:example.org:myPolicy" />

The way I could resolve that is to get the tModel from a UDDI registry, then follow the overviewURL (e.g., [4]) (using HTTP GET) to retrieve a document that contains the current policy.

[4] http://tinyurl.com/jquaa#RegisteringReusablePolicyExpressions

Does WS-Policy provide a way to give someone who looks at this WSDL a hint as to the way they should go about resolving it?

If I have 100 WSDL descriptions with 100 different ways to resolve the PolicyReference, I will have an interoperability problem. I would imagine that there will emerge a few well-known ways to resolve the PolicyReference.

For example, if <wsp:PolicyReference URI="http://example.org/MyPolicy" />

It is reasonable to assume that the way to resolve it is to do HTTP GET, and expect in return a WS-Policy document.

However, if <wsp:PolicyReference URI="http://example.org/rss/user/tag" />, doing HTTP GET may not return a WS-Policy document directly. For example, it could return an RSS or Atom document whose items include something like

<enclosure url="http://www.example.org/MyPolicy"
type="application/wspolicy+xml" />

Note, http://www.w3.org/2006/09/13-ws-policy-minutes.html#item13
has some talk about media type and fragment identifiers for WSDL 1.1, but I didn't see anything about defining a media type for WS-Policy, such as, application/wspolicy+xml.

Or with even further indirection

<enclosure
url="http://www.example.org/registry?tModelKey=uddi%3Aexample.org%3AMyPolicy"
type="application/uddi+xml" />

In this scenario, the RSS/Atom feed includes an enclosure that points to a UDDI tModel, which in turn points to WS-Policy document.

For a slightly different approach, I could, for example, bookmark a bunch of URI's that return a UDDI tModel,
http://del.icio.us/rss/mitrepauld/uddixmltm

I could add a tag to those bookmarks that are used for reusable policy expressions, say "rpe".
http://del.icio.us/rss/mitrepauld/uddixmltm+rpe

This is would be a slightly different "policy retrieval algorithm", perhaps, because it has the <link> of the RSS feed point to the UDDI entry and not an <enclosure>.

I could add a tag "current" to the bookmarks to narrow it down further. When I create a new policy, I bookmark it with the "current" tag and then remove the "current" tag from the bookmark to the old policy.

My WSDL could have
<wsp:PolicyReference URI=" http://del.icio.us/rss/mitrepauld/uddixmltm+rpe+current" />

I'll discuss "policy retrieval algorithm" in a separate email.

Paul