- From: Monica J. Martin <Monica.Martin@Sun.COM>
- Date: Tue, 13 Feb 2007 10:32:47 -0800
- To: Sergey Beryozkin <Sergey.Beryozkin@iona.com>
- Cc: "public-ws-policy@w3.org" <public-ws-policy@w3.org>
Sergey, see inline (re: http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0017.html). Thanks. >> Others specific to Ignorable only: >> When strict mode is applied for matching, Ignorable exists on >> compatible assertions. > > beryozkin: I don't quite understand it. The requester's policy > assertion does not have to be marked as Ignorable > to match a provider's Ignorable assertion in the strict mode, right ? > Does the above text mean something else ? mm1: Sergey, we're only answering the first usage rule comment as to tailor the discussion. The Primer indicates that ignorable assertions are part of the policy alternative vocabulary and the Ignorable attribute may exist on assertions, see Section 3.4.1: When using the strict intersection mode ignorable assertions are part of the policy alternative vocabulary, so the |wsp:Ignorable| attribute does not impact the intersection result even when the |wsp:Ignorable| attribute value is “true”. The Framework is implicit on points (which is the basis of discussion). Attributes of assertions, i.e. assertion parameters, are not considered as part of the first approximation of an intersection algorithm, i.e. an assertion <A attribute1="xy"> would be compatible with <A Ignorable="true"/> in strict mode unless the definition of assertion A says otherwise. The difference is the assertion paramater exists outside of policy namespace while optional and ignorable exist within it. Interesting to question whether or not Ignorable may be handled differently in domain specific processing. Note in Primer Section 3.3: The assertion parameters are the opaque payload of an assertion. Parameters carry additional useful pieces of information necessary for engaging the behavior described by an assertion. In the XML representation, the child elements and attributes of an assertion excluding the child elements and attributes from the WS-Policy language XML namespace name, are the assertion parameters. For example @wsp:Optional and @wsp:Ignorable are not assertion parameters. These attributes (ignorable and an assertion parameter) are not part of policy intersection regardless of their origin. Saying that explicitly and in reference to mode may be helpful in the Primer. Sergey, on the other rules, we think you agree with this given your comments: The intersection algorithm allows the client to filter out assertions that it does not understand and that were marked Ignorable. This is the mustUnderstand inverse. We can discuss the others as we determine your comments and the others of the WG in more detail. Thanks. ======= > On wsp:optional and wsp:ignorable being on the same assertion : I'd > personally advocate prohibiting this combination in the compact form > thus making it absolutely clear that wsp:optional and wsp:ignorable > are different things. > Another option is to update the normalization algorithm from the > compact form : if wsp:optional and wsp:ignorable are present on the > same assertion, then given that wsp:optional *is* ignorable because it > won't be present in all the alternatives but not the other way around, > the assertion in the normal form does not retain a wsp:ignorable flag. > > I'd also present wsp:ignorable as a means to mark purely informational > assertions which do not require a client to take any actions which > affect its communication with the provider (possibly with visible wire > effects). Othewise the assertion must be presented as a normal > required assertion, possibley marked as wsp:optional in the compact form. > One still would be able to bypass all the restrictions by putting an > assertion which should be marked as wsp:ignorable in one of the > alternatives, that is using wsp:optional only in the compact form. But > at least with the primer's text and with the proposed restrictions > above the message will be clearer. > > Cheers, Sergey > ----- Original Message ----- From: "Monica J. Martin" > <Monica.Martin@Sun.COM> > To: "Prasad Yendluri" <prasad.yendluri@webmethods.com>; "Sergey > Beryozkin" <sergey.beryozkin@iona.com> > Cc: <public-ws-policy@w3.org> > Sent: Tuesday, January 30, 2007 9:58 PM > Subject: ...[GUIDELINES] Use of @wsp:optional and @wsp:Ignorable on an > assertion (Issue > >> Perhaps we should step back a bit, looking at the language in the >> specifications, and what guidance we provide to expand in the Primer >> and/or Guidelines. We acknowledged more work was required as we >> accepted resolution by Frederick for Issue 4041 and as implied by >> this Issue 4262 [1]. >> >> The discussion thus far indicates usage guidelines may apply for use >> of ignorable and perhaps ignorable where optional also applies. For >> example for the latter (usage guides indented herein): >> >> When a policy assertion can not be marked as optional (or is not >> marked as such) and Ignorable is used, that assertion is not >> optional (is required) for a client that does understand it. >> >> Others specific to Ignorable only: >> >> When strict mode is applied for matching, Ignorable exists on >> compatible assertions. >> >> It is conscious choice of the entity that does the intersection which >> mode it applies. One case where strict mode may apply is where the >> entire policy of the both sides apply. >> >> The intersection algorithm allows the client to filter out >> assertions that it does not understand and that were marked >> Ignorable. This is the mustUnderstand inverse. >> >> There is a provision for domain-specific processing in that all of >> the intersection algorithms are suggestions and the parties may >> choose to use different algorithms. >> >> After intersection the resulting policy could contain assertions >> marked with Ignorable and the resulting policy is applied to the >> messages. Those assertions that the client understands are not >> ignored. >> >> Ignorable doesn't designate ignor behavior. >> >> This is draft text so take that in context. Thanks. >> >> Fabian and Monica >> >> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4262 >> >> >> >>> Prasad Yendluri wrote: Sergey, >>> I understand what you are saying, namely in some cases (perhaps most) >>> marking "ignorable" assertions as optional also, does not make >>> sense, from a >>> common sense perspective. However, the specification does not >>> impose any >>> restrictions, or more specifically it does not preclude assertions >>> being >>> marked as both optional and ignorable. If it is really desirable that >>> "ignorable" assertions should not be marked optional and thereby >>> providing >>> an alternative where, the ignorable assertions do not even be >>> present, then >>> the restriction needs to be present, preferably in the core >>> specification. >>> Barring that, minimally I would like this be addressed and clarified, >>> pointing out why this is not a best practice, in the guidelines >>> document. =========== >>> [mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin >>> Hi >>> It's difficult not to start thinking that a strict mode is not >>> working as >>> expected. As far as I understand, one of the goals of the strict >>> mode is to >>> ensure that ignorable assertions will cause the intersection to fail >>> unless >>> the consumer explicitly recognizes them. That is, a consumer wishes >>> to fail >>> if it encounters unknown assertions which are ignorable for the >>> intersection >>> purposes, for ex, a consumer does not wish this assertion to go >>> unnoticed : >>> >>> <foo:logging wsp:ignorable="true"/> >>> <foo:makeYourDataAvailable wsp:ignorable="true"/> >>> >>> Still, a producer can just mark assertions like these ones as >>> wsp:optional >>> and bypass the strict mode, as optionality possesses the 'ignorability' >>> property unless some further restrictions are introduced >>> =========== >>> Prasad Yendluri wrote: wsp:Optional is just a syntactic sugar, for >>> two alternatives one with the assertion and one without. >>> >>> If an assertion say "A" also had wsp:Ignorable=true, then one >>> alternative >>> would have the assertion A with @wsp:Ignorable=true and other where the >>> assertion A would not be present. This is what we discussed at the >>> Burlington f2f IIRC. What is the use case that would preclude the >>> use of >>> both on the same assertion? If we find one, then this issue becomes >>> a LC >>> issue on the Framework document. >>> =========== >>> [mailto:public-ws-policy-request@w3.org] On Behalf Of Henry, William >>> Is this really the case? I'm not sure the intent was ever to have >>> both these >>> in that same assertion. Was it? >>> >>> I'd have thought the guidelines should have shown that these were >>> for two >>> different types of use case. Can some explain the use case that was >>> dreamed >>> up where the make sense >>> together? >>> ============ >>> re: Issue.....Title: Provide clear guidance on the specification of >>> @wsp:optional=true and >>> @wsp:Ignorable=true on the same assertion >>> Target: Guidelines Document >>> Description: >>> The framework specification does not explicitly state if an >>> assertion can be >>> marked both optional and ignorable. However, as we discussed since >>> @wsp:optional is just a syntactic simplification, it is permitted to >>> mark an >>> assertion with both the @wsp:optional and @wsp:Ignorable with the >>> value of >>> "true" for both. >>> >>> I ask that the guidelines document add some guidance to clarify this >>> aspect. >>> >>> Justification: No clarify in this aspect anywhere else >>> >>> Proposal: Add a text to the guidelines document to clarify that both >>> the >>> attributes wsp:optional and wsp:Ignorable with the value of "true" >>> for both, >>> can be specified on the same assertion >>> >>> Regards, >>> Prasad >>> >>> >> > > >
Received on Tuesday, 13 February 2007 18:32:55 UTC