- From: Monica J. Martin <Monica.Martin@Sun.COM>
- Date: Tue, 30 Jan 2007 13:58:28 -0800
- To: Prasad Yendluri <prasad.yendluri@webmethods.com>, Sergey Beryozkin <sergey.beryozkin@iona.com>
- Cc: public-ws-policy@w3.org
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, 30 January 2007 21:58:44 UTC