Re: ...[GUIDELINES] Use of @wsp:optional and @wsp:Ignorable on an assertion (Issue

Hi

> Others specific to Ignorable only:
> 
>    When strict mode is applied for matching, Ignorable exists on
>    compatible assertions.

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 ?

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
>>
>