W3C home > Mailing lists > Public > public-ws-policy@w3.org > January 2007

[Bug 4210] WSDL WG Editorial comments on Framework

From: Paul Cotton <Paul.Cotton@microsoft.com>
Date: Fri, 12 Jan 2007 16:09:31 -0800
To: "public-ws-policy@w3.org" <public-ws-policy@w3.org>
Message-ID: <4D66CCFC0B64BA4BBD79D55F6EBC225720F817D9CA@NA-EXMSG-C103.redmond.corp.microsoft.com>


-----Original Message-----
From: public-ws-policy-qa-request@w3.org [mailto:public-ws-policy-qa-request@w3.org] On Behalf Of bugzilla@wiggum.w3.org
Sent: January 12, 2007 6:56 PM
To: public-ws-policy-qa@w3.org
Subject: [Bug 4210] WSDL WG Editorial comments on Framework


http://www.w3.org/Bugs/Public/show_bug.cgi?id=4210

           Summary: WSDL WG Editorial comments on Framework
           Product: WS-Policy
           Version: LC
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Framework
        AssignedTo: fsasaki@w3.org
        ReportedBy: jonathan@wso2.com
         QAContact: public-ws-policy-qa@w3.org


1. No relationship to XML Base [1] is defined as of yet in Framework. As issue
has been raised on this with the WG [2].

2. Policy Assertion (3.1)
- The definition of policy assertion appears to be redundant.
- The style of artefact definition appears a bit cumbersome ("[Definition: An
ignorable policy assertion is ...]"). As is these definitions appear to be
placeholders. In their place text could be written that flows better, e.g. the
second paragraph of 3.1 could be written as: "An assertion MAY indicate that it
is an ignorable policy assertion (see 4.4 Ignorable Policy Assertions). An
ignorable policy assertion is one that may be ignored for policy intersection
(as defined in 4.5 Policy Intersection). By default, an assertion is not
ignorable for policy intersection."

3. Policy Alternative (3.2)
- The definition of policy alternative needs some elaboration (e.g. "A policy
alternative is a potentially empty collection of policy assertions which are
used indicate an available set of behaviors."). As is it doesn't lay out well
what alternatives actually are before delving into their semantics. The same
approach can be applied to 3.3 Policy.
- It is suggested that "(i) Normal form of a policy expression (ii) Compact
form of a policy expression (iii) Identification of policy expressions and (iv)
Policy intersection" be reordered to read "(i) Normal form of a policy
expression (ii) Identification of policy expressions (iii) Compact form of a
policy expression and (iv) Policy intersection."

4. Policy Identification (4.1)
- Some additional clarification may be needed around the use of xml:id in the
Framework, as in associating a policy expression with the IRI-reference.

5. Compact Policy Expression
- Document Information Item should reference its definition in XML Infoset [3],
as does Element Information Item [4].

6. Policy Assertion Nesting (4.3.2)
- A nested policy in normal form has the same structure as the enclosing
policy. However, the example in this section does not reflect this. An issue
has been raised with the WG and a resolution proposed [5].

7. Security Considerations (5)
- Policy/assertion "signing" is RECOMMENDED but there is no reference to what
is indicated by "signing" or to any standards work (W3C or other) around any
such signing. Does this refer to WSS signatures [6]? The use of "signing"
itself in this language should reference any such standard(s).

[1] http://www.w3.org/TR/2001/REC-xmlbase-20010627/
[2] http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0022.html
[3] http://www.w3.org/TR/2004/REC-xml-infoset-20040204/#infoitem.document
[4] http://www.w3.org/TR/2004/REC-xml-infoset-20040204/#infoitem.element
[5] http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0034.html
[6]
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
Received on Saturday, 13 January 2007 00:10:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:45 GMT