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

Comments below.

Paul

At 12:29 AM 2007-10-23, Asir Vedamuthu wrote:
> > 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.

Are you suggesting that the example above would go into 2.10 without 
my proposed text, and instead of my proposed text you would make the 
change below (s/As such, .../.../)?


> > 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.

Right, but I say it may not be obvious because you would need to know 
(via out of band mechanisms) the endpoint of the UDDI inquiry API to 
which you send the get_tModelDetail, and then what you get is a 
tModel.  Assuming it is a tModel for a "reusable policy expression" 
conforming to WS-Policy Attachment section 6.3, then you would need 
to use the overviewURL to retrieve the policy expression.  And you 
can't tell from the @URI that it is a tModelKey; if it is a 
bindingKey, then the "policy-aware client" would need to send 
get_bindingDetail, then parse the bindingTemplate to get the 
identifier for the "remote policy expression" in the (UDDI v3) 
categoryBag/keyedReference/@keyValue (see Attachment sections 6.2 and 6.4)

categoryBag/keyedReference/@tModelKey


>In the Primer, section 2 is about breadth. Section 3 provides more 
>in-depth materials.

Agree that section 2 (Basic Concepts) should not get into too much 
detail, and section 3.6 is probably a better place dive a little deeper.

>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])./

My other comment/issue [0] proposed changes to 3.6 to touch on the 
UDDI aspect of policy attachment and retrieval.
[0] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5219

I think that change is still applicable even if the "As such..." line 
is changed in 2.10.

Note that 3.6 also links back to 2.10 when it discusses WSDL 
import.  It may be confusing (circular reference) if 2.10 directs the 
reader to 3.6, then back again to 2.10.

I guess WSDL import is a special case, and therefore, more 
appropriate for section 3 (Advanced Concepts) rather than section 2 
(Basic Concepts).

Perhaps a better way to handle this is to limit discussion in section 
2.10 to references within the same document using either xml:id or 
wsu:Id, but put discussion of the Name attribute and references to 
external policy expressions in Section 3.6.
End 2.10 after example 2-18 and move the text starting from "The Name 
attribute ..." and examples 2-19 and 2-20 (and my proposed example 
2-20a) to section 3.6

Earlier in 2.10 it states "There are three mechanisms to identify a 
policy expression: the wsu:Id, xml:id and Name attributes. "  So, you 
may want to add the following line after example 2-18:

The Name attribute and referencing policy expressions outside of the 
same document are discussed in section 3.6.

I took a stab at these changes, see the attachment to this email.
I have a questions at the end, which I will repeat here:

Does Policy/@Name have to match PolicyReference/@URI ? Is it okay to 
have Policy/@Name="http://x.example.com/policy/common" and 
PolicyReference/@URI="uddi:3bed4710-1f46-11dc-899e-391cf3b1899c". 
Should Policy/@Name="uddi:3bed4710-1f46-11dc-899e-391cf3b1899c" ?

Also, notice that I set the @keyValue to the IRI that ## identifies 
## the policy, but overviewURL is set to the IRI that is to be used 
for ## retrieval ## of the policy expression. This is based on my 
reading of Attachment 6.2 and 6.3., i.e. (6.2) "The keyValue MUST be 
the IRI that identifies the policy expression." (6.3) "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."

The example in the Attachment REC is a case where the IRI to ## 
identify ## is the same as the IRI to ## retrieve ## the policy 
expression, but the specs and primer are very clear that this is not 
necessarily the case. Example xxx tries to illustrate that more explicitly.

Perhaps the bit about WSDL import should be moved to section 3.5?


Paul


>[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