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

Re: Initial proposal for Issue 4041

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Tue, 20 Feb 2007 16:54:53 -0500
Message-Id: <E4556822-6133-4059-BC0D-973A0D6DCFAD@nokia.com>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, <public-ws-policy@w3.org>, "ext Prasad Yendluri" <prasad.yendluri@webmethods.com>, "ext Vedamuthu Asir" <asirveda@microsoft.com>
To: ext Sergey Beryozkin <sergey.beryozkin@iona.com>

comments inline

regards, Frederick

Frederick Hirsch
Nokia


On Feb 20, 2007, at 6:07 AM, ext Sergey Beryozkin wrote:

> Hi
>
> Here's some comments on the section 2.7 "Ignorable assertions" in  
> the primer.
>
> I disagree with the way this section introduces ignorable  
> assertions. Specifically it states that Contoso marks the Logging  
> assertion as wsp:ignorable in order to address the concerns of the  
> customers who might be concerned about Contoso doing logging. I  
> feel that this is not a right message.

The intent is to provide a logging assertion to allow those who care  
to know about it, but to allow others to ignore it. Do you disagree  
with that?

> What this section actually does in the introduction is it explains  
> what a strict mode can be used for, but not why providers would  
> mark their assertions as wsp:ignorable. It's requesters who are  
> selecting strict mode if they're uncomfotable with ignoring the  
> unrecognized assertions.
>

Ignorable and strict go together, so it is about use of ignorable and  
then explains the distinction of strict and lax

> Providers mark their assertion as wsp:ignorable not because they're  
> concerned about some requesters be uneasy about the semantics of  
> this (possibly unknown to them) assertion and hence choosing the  
> intersection to fail.
>
> Providers do so in order to widen the reach of such the assertion.  
> First of all, by including such the assertion in their policy,  
> providers obviously want this assertion be of useful info to  
> someone out there who understands what it's all about. At the same  
> time, they want those requesters who unaware what it's about to be  
> able to ignore it.

agreed, that was the intent of the provided text.

> I propose for this section' first paragraph be rewritten. I also  
> suggest to present wsp:ignorable as informational assertions in the  
> second paragraph, this would mark a clearer border between  
> wsp:ignorable and wsp:optional. Additionally, I would propose to  
> use a more realistic assertion example instead of <logging/>
>

Can you please propose a revision?

what do you propose instead of logging, can you please provide a  
proposal? I think logging makes sense since it is an example of  
useful information that not all clients care about.


> Thanks, Sergey
>
> > Attached is Word version as well.
> >
> > regards, Frederick
> >
> > Frederick Hirsch
> > Nokia
> >
> >
> > On Jan 15, 2007, at 10:26 AM, Frederick Hirsch wrote:
> >
> >> Attached are both clean and red-lined versions (PDF)
> >>
> >> regards, Frederick
> >>
> >> Frederick Hirsch
> >> Nokia
> >>
> >>
> >> On Jan 11, 2007, at 11:57 AM, ext Prasad Yendluri wrote:
> >>
> >>> Frederick,
> >>>
> >>> Thanks for the updated version that accounted for my comments.
> >>> I am good with your changes.
> >>>
> >>> Could you please send a version that does not have the change  
> marks?
> >>>
> >>> Regards,
> >>> Prasad
> >>>
> >>> -----Original Message-----
> >>> From: public-ws-policy-request@w3.org
> >>> [mailto:public-ws-policy-request@w3.org] On Behalf Of Frederick
> >>> Hirsch
> >>> Sent: Thursday, January 11, 2007 6:52 AM
> >>> To: ext Prasad Yendluri
> >>> Cc: Hirsch Frederick; public-ws-policy@w3.org
> >>> Subject: Re: Initial proposal for Issue 4041
> >>>
> >>> [removing editors from cc list since this is on the work group  
> thread
> >>> now which includes all editors]
> >>>
> >>> Prasad
> >>>
> >>> comments in line, but I agree with your concerns and attach a
> >>> concrete amendment to the draft.
> >>>
> >>> This message contains 4 proposed amendments to the draft  
> distributed
> >>> to the work group
> >>> (ignorable-proposal-v3.pdf). I've attached a red-line to show in
> >>> context the proposed amendments.
> >>>
> >>> Amendment #1
> >>> Replace 2nd paragraph lines 16-24 with the following text:
> >>>
> >>> "The use of the Ignorable attribute allows providers to clearly
> >>> indicate which policy assertions indicate behaviors that don't  
> always
> >>> manifest on the wire and may not necessarily be of concern to a
> >>> requestor. Using the Optional attribute would be incorrect in this
> >>> scenario, since it would indicate that the behavior would not  
> occur
> >>> if the alternative without the assertion were selected. "
> >>>
> >>> Amendment #2
> >>> Remove 3rd paragraph entirely (lines 26-29).
> >>>
> >>> Amendment #3
> >>>
> >>> Add following text to follow second paragraph (at line 25)
> >>> "It is incumbent of Providers to declare the behaviors that  
> will be
> >>> engaged using policies although those behaviors may not exhibit  
> wire
> >>> level manifestations. The Ignorable attribute allows them (policy
> >>> providers) to do so."
> >>>
> >>> Amendment #4
> >>>
> >>> Since the material around proposed 2.7 is written in terms of  
> XML, I
> >>> propose we uniformly refer to ignorable in terms of the Ignorable
> >>> attribute. Please see the red-line for details of this change.
> >>>
> >>> Thanks Prasad for the useful review.
> >>>
> >>>
> >>> Frederick Hirsch
> >>> Nokia
> >>>
> >>>
> >>> On Jan 10, 2007, at 7:02 PM, ext Prasad Yendluri wrote:
> >>>
> >>>> Hi Frederick,
> >>>>
> >>>>
> >>>>
> >>>> Again thanks for the detailed work on this.
> >>>>
> >>>>
> >>>>
> >>>> I have a few comments as enumerated below:
> >>>>
> >>>>
> >>>>
> >>>> 1.       Lines 29-31 state
> >>>>
> >>>>   "To mark an assertion as "Ignorable" the policy assertion
> >>>> definition must be examined to determine that it has no wire
> >>>> behavior and that it is allowed to be marked as Ignorable"
> >>>>
> >>>>
> >>>>
> >>>> This is not true. We discussed this aspect during the discussion
> >>>> that added the "ignorable" marker but, the current WS-Policy 1.5
> >>>> Framework specification does not impose any such restrictions on
> >>>> assertions that can be marked "Ignorable". All assertions that  
> have
> >>>> wire manifestation or not can be marked "Ignorable". I raised  
> this
> >>>> aspect myself at the Boston F2F and I was overruled J
> >>>
> >>> I agree and believe we should remove this restriction. I propose
> >>> amendment #1 to fix this.
> >>>
> >>> (Note that if there is a wire manifestation then I'm not sure I
> >>> understand how it can be ignored)
> >>>> 2.  The sentence that follows the above text "Assertion authors
> >>>> need to clarify that assertions may be marked as "Ignorable".
> >>>>
> >>>> Not sure what this is conveying? Or how it follows the no wire
> >>>> manifestation aspect of ignorable assertions stated above.
> >>>>
> >>>> Need more clarity on what this is saying.
> >>>
> >>> Along with your first point, if we adjust that, then this can be
> >>> removed.
> >>>
> >>>>
> >>>>
> >>>> The famous one (editor's special :):  "The Ignorable marker  
> allows
> >>>> them (policy providers) to be truthful."
> >>>>
> >>>>
> >>>> The Ignorable marker does not make the policy providers truthful.
> >>>>
> >>>> A simple "to do so" is enough, as the previous statements clearly
> >>>> articulate the need to declare all behaviors that will be  
> engaged.
> >>>>
> >>>>
> >>>>
> >>>> I suggest a rephrase as follows:
> >>>>
> >>>> "It is incumbent of Providers to declare the behaviors that  
> will be
> >>>> engaged using policies although those behaviors may not exhibit
> >>>> wire level manifestations.
> >>>>
> >>>> The Ignorable marker allows them (policy providers) to do so."
> >>>>
> >>>>
> >>>
> >>> I prefer this.
> >>>
> >>>> 4.      The "Ignorable" is referred to as different things
> >>>> throughout the description.
> >>>>
> >>>> "The Ignorable marker allows them." , "when Ignorable flag is set
> >>>> to "true", "the Ignorable property does not impact", "..Ignorable
> >>>> attribute"
> >>>>
> >>>>      I suggest we stick a consistent of way characterizing it.
> >>>
> >>>
> >>> Agree, thanks for reminding me of this one.
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Prasad
> >>>>
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: public-ws-policy-eds-request@w3.org [mailto:public-ws- 
> policy-
> >>>> eds-request@w3.org] On Behalf Of Frederick Hirsch
> >>>> Sent: Wednesday, January 10, 2007 12:27 PM
> >>>> To: public-ws-policy@w3.org
> >>>> Cc: Hirsch Frederick; WS-Policy Editors W3C
> >>>> Subject: Initial proposal for Issue 4041
> >>>>
> >>>>
> >>>>
> >>>> Attached is an initial draft proposal for issue 4041 [1], adding
> >>>>
> >>>> ignorable in the Primer. Note that this issue did not include  
> adding
> >>>>
> >>>> material on ignorable to the Guidelines, which would be related.
> >>>>
> >>>>
> >>>>
> >>>> This draft does not reflect the full consensus of the editors,  
> since
> >>>>
> >>>> not every editor had a chance to review it. However we felt  
> that it
> >>>>
> >>>> would be useful to provide to the committee in advance of the  
> F2F to
> >>>>
> >>>> show the direction of this work. Additional changes may be  
> needed.
> >>>>
> >>>>
> >>>>
> >>>> Thanks
> >>>>
> >>>>
> >>>>
> >>>> regards, Frederick
> >>>>
> >>>>
> >>>>
> >>>> Frederick Hirsch
> >>>>
> >>>> Nokia
> >>>>
> >>>>
> >>>>
> >>>> [1] <http://www.w3.org/Bugs/Public/show_bug.cgi?id=4041
> >>>>
> >>>>
> >>>
> >>
> >> <ignorable-proposal-v3-FH-clean.pdf>
> >> <ignorable-proposal-v3-FH-red-line.pdf>
> >
> >
Received on Tuesday, 20 February 2007 21:55:21 GMT

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