RE: Primer LCWD [was RE: RE: Policy Retrieval Algorithms]

> The following example shows a policy expression ...
> <PolicyReference URI="uddi:3bed4710-1f46-11dc-899e-391cf3b1899c"/>

The proposed example is a good addition to section 2.10, Primer.

> and mechanisms for retrieving the
> policy expression identified by @URI may not be obvious.

IRI has a scheme and the scheme defines a mechanism to resolve IRIs. In your UDDI example, the 'uddi' scheme [1] and a mechanism to resolve tModels [2] are defined by the UDDI spec.

In the Primer, section 2 is about breadth. Section 3 provides more in-depth materials. In particular, section 3.6 [3] covers policy retrieval mechanisms in detail and provides several examples. We suggest not to add such details in Section 2.10 instead add a sentence that provides a forward pointer to Section 3.6. That is:

s/As such, referencing a policy expression using the Name attribute relies on additional out of band information./As such, referencing a policy expression using the Name attribute relies on additional out of band information and is outside the scope of the Web Services Policy Framework and Attachment (See Section 3.6 Policy retrieval [3])./

[1] http://uddi.org/pubs/uddi-v3.0.2-20041019.htm#_Ref44756332
[2] http://uddi.org/pubs/uddi-v3.0.2-20041019.htm#_Toc85908094
[3] http://www.w3.org/TR/2007/WD-ws-policy-primer-20070928/#policy-retrieval

Regards,

Asir S Vedamuthu
Microsoft Corporation


-----Original Message-----
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Paul Denning
Sent: Friday, October 19, 2007 10:14 AM
To: public-ws-policy@w3.org
Subject: Primer LCWD [was RE: RE: Policy Retrieval Algorithms]


I never had the time to follow up on Paul's
suggestion (from a year ago) [4] regarding
WS-PolicyAttachment, but perhaps a comment is in
order for the Primer WG Note (now in LCWD) to at
least caution implementers that @URI may or may
not be resolvable, and if it is resolvable that
@URI may not be a direct link to a representation
whose content type is application/wspolicy+xml.

[2]
http://www.w3.org/TR/2007/WD-ws-policy-primer-20070928/#Referencing_Policy_Expressions
[3] http://www.w3.org/TR/2007/REC-ws-policy-20070904/#Policy_References
[4] http://lists.w3.org/Archives/Public/public-ws-policy/2006Oct/0134.html

Suggest adding the following text to the end of
section 2.10 [2] (pertaining to example 2-20):

<proposal>

Note that the value of the URI attribute
information item (defined in [3]) may or may not
be directly resolvable to retrieve the policy
expression.  This attribute (@URI) may be an
identifier, and mechanisms for retrieving the
policy expression identified by @URI may not be
obvious.  Such mechanisms are out-of-scope for
[Web Services Policy Framework] and [Web Services Policy Attachment].

The following example shows a policy expression
identified using a UDDI tModelKey, which may
refer to a tModel that references the policy
expression as described in section 6.3 of [Web Services Policy Attachment].

Example 2-20a. PolicyReference to Common Policy Expression via UDDI

<PolicyReference URI="uddi:3bed4710-1f46-11dc-899e-391cf3b1899c"/>


</proposal>

Below snippet may help editors add this example
to the document.  If you accept this proposed
change, you may want to re-number the examples.

<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
2-20a.</span> PolicyReference to Common Policy Expression</i></p>


<div class="exampleInner">
<pre>
&lt;PolicyReference URI="uddi:3bed4710-1f46-11dc-899e-391cf3b1899c"/&gt;
</pre></div>
</div>


What I am not clear about is constraints on the
value of wsp:Policy/@wsp:Name, like in Example
2-19.  For my UDDI example above, would the @Name
need to be the UDDI tModelKey?


<Policy Name="uddi:3bed4710-1f46-11dc-899e-391cf3b1899c">
   <mtom:OptimizedMimeSerialization wsp:Optional="true"/>
   <wsam:Addressing>...</wsam:Addressing>
</Policy>


(There are probably some related words that
should go into section 3.6, but I'll send a separate email on that.)

Paul

At 01:17 PM 2006-10-18, Paul Cotton wrote:
>I agree with Dan that nothing more is actually
>in the Policy spec to specify how the resources can be retrieved.
>
>Paul Denning: If you think something specific
>needs to be added please open a new WS-Policy
>issue [1] and give us a clear rationale for the missing functionality.
>
>/paulc
>
>[1] http://www.w3.org/2002/ws/policy/#issues
>
>
>Paul Cotton, Microsoft Canada
>17 Eleanor Drive, Ottawa, Ontario K2E 6A3
>Tel: (613) 225-5445 Fax: (425) 936-7329
>mailto:Paul.Cotton@microsoft.com
>
>
>
>
>From: public-ws-policy-request@w3.org
>[mailto:public-ws-policy-request@w3.org] On Behalf Of Daniel Roth
>Sent: October 11, 2006 11:26 AM
>To: Paul Denning; public-ws-policy@w3.org
>Subject: RE: Policy Retrieval Algorithms
>
>Hi Paul,
>
> > there is no requirement that the IRI be resolvable
>
>I would also note that the IRI CAN be
>resolvable.  Using resolvable IRIs seems like a
>natural and interoperable way of dealing with external references.
>
> > defining a way to identify a retrieval mechanism could/should be in scope.
>
>This seems unnecessary since IRI's already
>define a way to specify how to resolve
>them.  Supporting more creative resolution
>mechanisms seems like a Policy vNext feature.
>
>Daniel Roth
>
>
>From: public-ws-policy-request@w3.org
>[mailto:public-ws-policy-request@w3.org] On Behalf Of Paul Denning
>Sent: Friday, October 06, 2006 12:47 PM
>To: public-ws-policy@w3.org
>Subject: Policy Retrieval Algorithms
>
>[1] http://tinyurl.com/ot5x5#Policy_References
>
>Section 4.3.4 states
>
>"...there is no requirement that the IRI be
>resolvable; retrieval mechanisms are beyond the scope of this specification."
>
>I would agree that defining various retrieval
>mechanisms would be out of scope, but defining a
>way to identify a retrieval mechanism could/should be in scope.
>
>Perhaps adding
>
><proposal>
>
>wsp:PolicyReference/@RetrievalAlgorithm
>
>   This optional URI attribute specifies the
> Retrieval Algorithm being used to resolve an
> external policy expression identified by ./@URI.
>
></proposal>
>
>
>Note that this is modeled after the
>DigestAlgorithm.  You would not provide @Digest
>without specifying the @DigestAlgorithm used to calculate it.
>
>@Digest is opaque and you cannot determine the
>digest algorithm by looking at its value.
>
>Likewise, we should treat @URI as opaque and
>provide an identifier for the algorithm that can
>be used to resolve the external policy expression.
>
>Paul

Received on Tuesday, 23 October 2007 04:29:29 UTC