RE: RE: Guidelines Document

Thanks for the explanation.  I agree that no changes are needed here.

/paulc

________________________________________
From: public-ws-policy-request@w3.org [public-ws-policy-request@w3.org] On Behalf Of public-ws-policy-request@w3.org [public-ws-policy-request@w3.org]
Sent: October 30, 2006 5:40 PM
To: Paul Cotton; Maryann Hondo
Cc: public-ws-policy@w3.org
Subject: RE: Guidelines Document

Paul,

You made a point about the RM Policy below for Section 5.1.

The specification that we used is [1]. In this document, there are
indeed 3 assertions defined, one for WSRM itself the other 2 wrt
securing the sequence. I am wondering whether you had the previous
version of the RM spec in mind, but that is not what is used.

Thanks.

--umit

[1]
http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-spec-cd-04.pdf


> -----Original Message-----
> From: Paul Cotton [mailto:Paul.Cotton@microsoft.com]
> Sent: Friday, Oct 20, 2006 3:15 PM
> To: Yalcinalp, Umit; Maryann Hondo
> Cc: public-ws-policy@w3.org
> Subject: RE: Guidelines Document
>
> Initial set of editorial comments:
>
> 1. Section 5.5 Comparison of Nested and Parametrized Assertions
>
> Change "Parametrized" to "Parameterized" in section title in
> TOC and later in the document.
>
> 2. Section 1. Introduction
>
> " WS-Policy Assertions are xml expressions"
>
> Change "xml" to "XML".
>
> 3. Abstract
>
> " Web Services Policy 1.5 - Guidelines for Policy Assertion
> Authors is a guideline for assertion authors that will work
> with the Web Services Policy 1.5 - Framework and Web Services
> Policy 1.5 - Attachment specifications to create domain
> specific assertions."
>
> Add pointers to references for "Web Service Policy 1.5 -
> Framework" and "Web Services Policy 1.5. Attachment" since
> this is the first time they are referenced.
>
> Do this for other documents referenced in the document as well.
>
> 4. Section 1. Introduction
>
> "B. XML Namespaces lists all the that are used in this
> document. (XML elements without a namespace prefix are from
> the Web Services Policy XML Namespace.)"
>
> Change "all the that" to "all the namespace prefixes that".
>
> 5. Section 2.1.1
>
> "An example of a domain specification"
>
> Change "specification" to "specification".
>
> 6. Section 2.1.1
>
> " The WS-Security authors have defined their scope as follows"
>
> Change "WS-Security" to "WS-SecurityPolicy".
>
> 7. Section 2.1.3
>
> " WS-PolicyFramework and WS-PolicyAssertions specifications."
>
> I think this is trying to refer to the Framework and
> Attachment specification.  If so then change this to:
>
> "WS-Policy Framework and WS-Policy Attachment specifications."
>
> 8. Section 2.1.3
>
> " that can reflect its on the wire message behavior"
>
> Change "its" to "it's".
>
> 9. Section 2.1 3
>
> " Whe deploying services with policies it is useful"
>
> Change to:
>
> "When deploying services with policies it is useful".
>
> 10. Section 3.1
>
> " A referencing mechanism is very useful in a tooling
> environment or when creating a domain specific attachment in
> multiple WSDL files, EPRs, in which the same set of policies
> are expected to be applied."
>
> "EPRs" should be defined and a reference provided.
>
> Change "in multiple WSDL files, EPRs" to " in multiple WSDL
> files or EPRs".
>
> 11. Section 4
>
> "is marked as optional using the @optionalattribute"
>
> There is a missing space between "@optional" and "attribute".
>
> 12. Section 5.1
>
> "New aurthors are encouraged to look at Web Services Reliable
> Messaging Policy to see an example of a relatively simple
> domain that has defined 3 assertions."
>
> Change "aurthors" to "authors".
>
> I don't believe this reference actually defines 3 assertions
> any longer.  Please check.
>
> 13. Section 5.2
>
> " it is important to identify whether or not the domain is
> self containted"
>
> Change "self contaited" to "self-contained".
>
> 14. Section 5.2
>
> " will also need to have community supportin implementation"
>
> Fix "supporting".
>
> 15. Section 5.3
>
> "thesp:TransportBinding policy assertion"
>
> Missing space after "the".
>
> 16. Section 5.3
>
> " The sp:AlgorithmSuite is a nested policy assertion of
> thesp:TransportBinding policy assertion. Thesp:AlgorithmSuite
> assertion requires"
>
> Missing space before "sp:" (two occurrences).
>
> 17. Section 5.6
>
> " it should be incorporated into the assertion design or in
> the message iteself"
>
> Change "itself" to "itself".
>
> 18 Section 5.7
>
> " in order to engage behaviors must not be forgotton"
>
> Change "forgotton" to "forgotten".
>
> 19. Section 5.10
>
> " Howeever, this approach only"
>
> Change "Howeever" to "However".
>
> 20. Section 5.11.1
>
> "It also promotes managability"
>
> Change "managability" to "manageability".
>
> 21. Section 8
>
> " how a fictitous company might utilize the WS-Policy Framework"
>
> Change "fictitous" to "fictitious".
>
> 22. Example 8.1
>
> "<wss:Security sopap:mustUnderstand ="1">"
>
> Change "sopap:" to "soap:".
>
> 23. Example 8.2
>
> "<sp:TransportBinding>lt;/spTransportBinding>
>
> Fix missing "<".
>
> 24.  Section 8
>
> " The sp:TransportBinding element is a policy assertion.The"
>
> Add two spaces at end of sentence and before "The".
>
> 25. Section 8
>
> " The first policy is shown in Figure X,"
>
> Fix the bad reference to Figure X.  There are other bad
> references to Figure Y.
>
> /paulc
>
> 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 Yalcinalp, Umit
> Sent: October 19, 2006 7:58 PM
> To: public-ws-policy@w3.org
> Subject: Guidelines Document
>
> All,
> Please find the first version of the guidelines document in
> [1] and send comments/issues.
> Frederick, would you verify the comments you have raised has
> been adressed to your satisfaction.
> Regards,
> --umit
> [1]
> http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-g
> uidelines.html?content-type=text/html;%20charset=utf-8
> ----------------------
> Dr. Umit Yalcinalp
> Architect
> NetWeaver Industry Standards
> SAP Labs, LLC
> Email: umit.yalcinalp@sap.com Tel: (650) 320-3095
> SDN: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238
>

Received on Tuesday, 31 October 2006 01:47:22 UTC