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

>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, >.../.../)?

Yes.

>If the referenced policy expression is not in the
>same XML document as the reference, then the referenced
>policy expression should be identified using the Name >attribute.

Not necessarily. You may reference policy expressions identified using the wsu:Id or xml:id attribute across XML documents (see Section 2.10 Primer).

I think it is hard to review your proposal without a diff version.

Regards,

Asir S Vedamuthu
Microsoft Corporation


-----Original Message-----
From: Paul Denning [mailto:pauld@mitre.org]
Sent: Tuesday, October 23, 2007 2:44 PM
To: Asir Vedamuthu; public-ws-policy@w3.org
Subject: 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-retrieva
>l
>
>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_Pol
>icy_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 Wednesday, 24 October 2007 05:24:15 UTC