Re: NEW ISSUE :Clarify usage of assertions with no behavioral requirements on the requester

Hello

I'd just like to explore a Proposal3 below in a bit more detail, copying it here for convenience :

Proposal 3. Introduce a new attribute wsp:provider-only and leave wsp:optional the way it is now.

Ex :

<Policy>
<m:MTOM wsp:optional="true"/>
<sp:security/>
<!-- of potential interest to requesters -->
<m:highlyAvailable wsp:provider-only="true"/>
<!-- server-specific stuff, of no interst to requesters-->
<m:myCustomServerLogging wsp:provider-only="true"/>
</Policy>

I'd like to remove server-only private stuff from here and concentrate only on capabilities which can be of interest to clients. Additionally, just for the purpose of this example I'll use wsp:advisory instead of wsp:provider-only because I just like wsp:advisory the name :-). Lets assume for a sec wsp:advisory is good for advertizing capabilities which can be ignored, server-specific stuff does not go here at all :

<Policy>
<m:MTOM wsp:optional="true"/>
<sp:security/>
<!-- of potential interest to requesters -->
<m:replicatable wsp:advisory="true"/>
</Policy>

Normal form :

<Policy>
<ExactlyOnce>
<All>
  <m:MTOM/>
  <sp:security/>
  <m:replicatable wsp:advisory="true"/>
</All>
<All>
  <sp:security/>
  <m:replicatable wsp:advisory="true"/>
</All>
</ExactlyOnce>
</Policy>

With wsp:optional we only mark optional assertions with some behaviours a requester will need to do.
With wsp:advisory we only mark things a requester may choose either to notice or ignore. Note that in the case of

I've thought more about it. I feel that it's kind of nice to have this separation of concerns. It makes sense. However I'm not sure that it makes things simplier/less unambiguous and confusing from a practical perspective :

* there's some overlap here in that both <m:MTOM/> and <m:replicatable/> are assertions a requester may optionally ignore. I just feel it will cause a lot a lot of confusion for users to figure out what should be marked as wsp:optional and wsp:replicatable (and then withsome standard wsp:local attribute marking pure server-only assertions :-)). I think the above example shows there's some ambiguity in  how <m:replicatable wsp:advisory="true"/> should be interpreted, it is in the alternative, but at the same time it's not because it can be ignored, it kind of dilutes the meaning of alternative.

* people would still be able to make <m:replicatable/> with wsp:optional
* people would likely start marking server-only assertions like <m:myCustomServerLogging/> with wsp:advisory/as well as with wsp:optional.
* it's not clear what a requester seeing <m:replicatable wsp:advisory="true"/> should do if does not understand what it means : just ignore it, or ignore it and warn a user ? 
* it's not clear what a requester seeing <m:myCustomServerLogging wsp:advisory="true"/> should do if does not understand what it means : just ignore it, or ignore it and warn a user ? this is an example of misused <m:myCustomServerLogging/> 
* I think it will slow down the requester's processing because even though <m:replicatable wsp:advisory="true"/> is marked as something which can be ignored a requester will still to process it and check if it's something it actually understands or not...

So far Proposal1 with a possible renaming to wsp:ignorable (and controversial 2 :-)) or Proposal4 (workaround) work for me...they just seem simplier, don't really require to do anything major. I'm not sure adding a new attribute will simplify/clarify things but lets think more Proposal3 too...

And I can't help waiting reading a Proposal 5 from Umit :-)

Enjoy
Sergey





  Hello,

  As part of the action assigned to me at the yesterday's concall, I'd like to offer to your attention 4 alternative proposals on how to resolve this issue which I believe have been mentioned before. I hope the subsequent discussions will point to a best/preferred/least controversial/simpliest/easy to understand solution. 

  I'd like to clarify that the purpose of resolving this issue is to have a guideline to policy authors which wish to advertize some of provider's capabilities. For ex, custom:free, custom:infoConfidential, custom:highlyAvailable, custom:replicatable which requesters can ignore or do something about.
  I'll add my own comments (S.B) to each of the proposal. However, please do not consider them as something which represents the position of Iona at this stage.


  Proposal1.
  Drastically simplify the meaning of wsp:optional. Explain that wsp:optional marks an assertion which can be ignored by a requester. In other words wsp:optional is identical in meaning to wsp:ignorable. Clearly state that wsp:optional assertions are by no means optional to a provider. 
  Explain that wsp:optional is a shortcut which simplifies creating different policy alternatives/vocabularies.
  Ex : <custom:infoConfidential wsp:optional="true"/> means a requester can ignore it.


  <S.B>  IMHO this is the simpliest solution which works. IMHO the current treatment of wsp:optional is too complicated. For ex, I think stating that if there's something a provider always does should not be marked as optional, otherwise it has to be optional will only confuse the users. IMHO it's wrong to say a provider optionally does MTOM, it always does it, one requester can choose an alternative with no MTOM but it does not mean the provider does not do it with the other requester. In other words an alternative is a piece of vocabulary. If MTOM is not in the selected alternative or not it does not mean that a provider has lost its capability to do MTOM. Viewing wsp:optional as a simple marker to indicate ignorable assertions is a very simple and working solution IMHO.
  <S.B> additional advantage is that it cleanly alligns with a proposed wsp:local attribute in that a user will be guided to mark server-specific stuff as being wsp:local. Imagine a GUI asking a question : 
  * "Is this assertion must be understood by a requester", YES-normal assertion.
  * "Is this assertion may be ignored by a requester", YES-multiple vocabularies are created, addional question : "Can this ignorable assertion be of any interest to a requester ?" NO - mark it as wsp:local.
  Nothing will prevent a user by exposing <myLocalServerOnlyAssertion/> by marking it as wsp:optional. This approach will proactively teach a user not to do it and only expose assertions which can be of interest to a requester.

  Proposal 2. Similar to proposal1. Drop wsp:optional altogether and find out how simple things have become. The reason it works is that if we forget about wsp:optional for a second, we can easily see that if one assertion is contained in one alternative and not in the other one then it's an optional/ignorable assertion. Another reason it works is that we can imagine policy authors using GUI tools which guide them. Imagine questions like : "Is this assertion must be understood by a requester" ? "Is this assertion may be ignored by a requester" ? Yes to the last question will result in a tool creating two alternative vocabularies.

  <S.B> the same comments as above
  <S.B> disadvantage is that more work will be requiored in a manual edit mode.

  Proposal 3. Introduce a new attribute wsp:provider-only and leave wsp:optional the way it is now.

  Ex :

  <Policy>
  <m:MTOM wsp:optional="true"/>
  <sp:security/>
  <!-- of potential interest to requesters -->
  <m:highlyAvailable wsp:provider-only="true"/>
  <!-- server-specific stuff, of no interst to requesters-->
  <m:myCustomServerLogging wsp:provider-only="true"/>
  </Policy>

  <S.B.> This works only if wsp:provider-only="true" are not stripped but this means wsp:provider-only="true" pointing to server-specific stuff only won't be stripped and be consistently leaked (and confuse a user at a design-time). If it's stripped then we'll lose <m:highlyAvailable/> which is of interest to knowledgeable requesters. IMHO it's a can of worms. 

  Proposal 4. Noop. Think of workarounds : multiple endpoints, different Policies, WSDLs, etc...


  Enjoy, Sergey.