W3C home > Mailing lists > Public > public-ws-policy@w3.org > September 2006

RE: ISSUE 3564: Optional Assertions may not be usable in all cir cumstances

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Thu, 28 Sep 2006 10:32:57 -0700
Message-ID: <2BA6015847F82645A9BB31C7F9D64165024175B6@uspale20.pal.sap.corp>
To: "Prasad Yendluri" <prasad.yendluri@webmethods.com>, "Glen Daniels" <gdaniels@progress.com>, "Daniel Roth" <Daniel.Roth@microsoft.com>, <public-ws-policy@w3.org>
Prasad, 
 
This is not a property of the primer. It is property of the model. 
 
If you have seen my response, in essence capabilities are the set of
things which one party CAN do. Requirements are a subset of those that
the party expressed that it WILL do. In essence all the members of a
vocabulary are capabilities that may or may not be required. We are not
dealing with mutually exclusive sets here. In real life people can not
be required to do things that they are not capable of (although my
management may have different perspective on that :-))
 
In an interaction, having two alternatives with wsp:optional="true" is
exactly the formulation of the following. It is an expression of a
capability, which turns into a requirement in one interaction as
expressed in the first alternative or absance of engagement in another
that gives the utilizing party a choice. 
 
HTH,
 
--umit
 


________________________________

	From: Prasad Yendluri [mailto:prasad.yendluri@webmethods.com] 
	Sent: Wednesday, Sep 27, 2006 2:11 PM
	To: Prasad Yendluri; Glen Daniels; Yalcinalp, Umit; Daniel Roth;
public-ws-policy@w3.org
	Subject: RE: ISSUE 3564: Optional Assertions may not be usable
in all cir cumstances 
	
	

	One more thing. The spec clearly states that "an assertion with
optional=true" is syntactic simplification to having two policy
alternatives, one with and one without the assertion.  So, applying the
interpretation of "optional=true" means "capability", and going from
compact to the normative form, is the alternative with the assertion in
the normative form a capability or a requirement? It does not have
optional=true on it anymore so it is a "requirement" per the
interpretation of the primer proposed? Did a "capability" in compact
form just turn into a "requirement" in the normative form?

	 

	Regards,

	Prasad

	
________________________________


	From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Prasad Yendluri
	Sent: Wednesday, September 27, 2006 1:55 PM
	To: Glen Daniels; Prasad Yendluri; Yalcinalp, Umit; Daniel Roth;
public-ws-policy@w3.org
	Subject: RE: ISSUE 3564: Optional Assertions may not be usable
in all cir cumstances 

	 

	Glen,

	 

	See some follow-up below.

	 

	Prasad

	 

	-----Original Message-----
	From: Glen Daniels [mailto:gdaniels@progress.com] 
	Sent: Wednesday, September 27, 2006 8:40 AM
	To: Prasad Yendluri; Yalcinalp, Umit; Daniel Roth;
public-ws-policy@w3.org
	Subject: RE: ISSUE 3564: Optional Assertions may not be usable
in all cir cumstances 

	 

	 

	Just chiming in here... I agree 100% with Umit's
characterization of

	requirement vs. capability, and I'd love to see the spec/primer
have

	more clarity on this.  Something a provider CAN do is a
capability.

	Something a consumer MUST do is a requirement.  That's it, IMHO.
The

	concept of "optional requirements" makes about as much sense to
me as

	"low-fat Twinkie". :)  I don't believe there's such a thing.

	 

	<PY> Currently the specification identifies a "policy assertion"
to be either a "requirement, or capability of a policy 

	subject.", and an assertion can be marked "optional" via the
"optional=true" attribute. So, the "optional"ity is applicable to either
form an assertion can take, viz. the requirement or capability. A
requirement is what the provider / policy subject expects / needs of its
clients / consumers to do. Some of these are what clients MUST do (per a
certain policy alternative) and other are clients have a choice to do or
not (i.e. optional).  Let us not get sidetracked by the term
"requirement" and the usual English meaning of it. WS-I Basic profile
calls its assertions "conformance requirements" and there are MUST and
MAY and SHOULD requirements. So, there can be "optional requirements",
which simply means things the client side is expected to do, but has an
"option" not to do.  If the "requirement" is not the right word perhaps
we need to find a better term but, as defined in the spec "an assertion
can be marked 'optional' and an assertion is either a "requirement" or
"capability"". 

	 

	The spec does not state an assertion marked "optional" is a
capability. That is what the primer was interpreting. 

	IMO that is a big jump to conclusion that the spec does not
grant. I think this aspect needs to be clarified in the spec rather than
interpreted at free by the primer.

	 

	 

	In the WS-Policy realm, if you see an optional assertion, that
indicates

	a capability which you as a consumer somehow choose (in a

	domain-specific fashion) to utilize or not.  

	 

	PY>Not necessarily. An assertion in general may not have any
capability implications for the provider.

	If the assertion calls for optionally sending a hardcopy of the
PO to a USPS address, in addition to submitting an online purchase order
request, it has no capability implications to the service that accepts
the online PO.

	 

	If you see a non-optional

	assertion in a selected alternative, then you MUST a) understand
and b)

	follow the rules of that assertion.  If the assertion indicates

	something that you don't have to do anything about (i.e. "I'll
respond

	within 10ms"), that's fine, but you still MUST understand it in
order to

	use that alternative - so in a way it's still a requirement.

	 

	PY>Fine it won't be marked optional then. It is a capability
that is not Optional :-)

	Fits fine with what the spec currently defines. If you chose a
policy alternative, you are expected to have understood all the
assertions in it (optional or not), anyway. 

	 

	If you want to actually be able to do something (litigate, etc)
if a

	policy claim like a round-trip guarantee is not honored, then
you need

	some kind of iron-clad indication that that policy was in fact
in

	effect.  This gets into the "policies with no wire
representation"

	discussion again....

	PY> Yes, we need to attain clarity and spell all these aspect
out in the spec.

	I would not the primer infer and state things that are not
clearly granted by the spec.

	 

	--Glen

	 

	> -----Original Message-----

	> From: public-ws-policy-request@w3.org 

	> [mailto:public-ws-policy-request@w3.org] On Behalf Of Prasad
Yendluri

	> Sent: Tuesday, September 26, 2006 9:09 PM

	> To: Yalcinalp, Umit; Prasad Yendluri; Daniel Roth; 

	> public-ws-policy@w3.org

	> Subject: RE: ISSUE 3564: Optional Assertions may not be 

	> usable in all cir cumstances 

	> 

	> Hi Umit,

	> 

	>  

	> 

	> See my response inline.

	> 

	>  

	> 

	> Prasad

	> 

	>  

	> 

	> ________________________________

	> 

	> From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com] 

	> Sent: Tuesday, September 26, 2006 5:07 PM

	> To: Prasad Yendluri; Daniel Roth; public-ws-policy@w3.org

	> Subject: RE: ISSUE 3564: Optional Assertions may not be 

	> usable in all cir cumstances 

	> 

	>  

	> 

	> Hi Prasad, 

	> 

	>  

	> 

	> It seems to me that perhaps the problem is the assumed 

	> definition of capability in the community and lets tease out 

	> a bit. You are right, there is an anomaly, but I am not sure 

	> I agree with the term "optional requirement". 

	> 

	>  

	> 

	> PY>Yes we need a clear definition of what we mean by 

	> capability. As clearly demonstrated by the exchange on this 

	> thread, there are multiple (at least two) interpretations. 

	> Your interpretation of capability is not what I was expecting 

	> but, I can grant that it can be considered a capability (of 

	> the provider), in that the provider can do it, if the 

	> consumer (client) side engages it. 

	> 

	>  

	> 

	> When MTOM assertion is present with optional="true" on a msg, 

	> I do not understand why you think it as a requirement. >From 

	> the perspective of the service, it is an optimization that is 

	> available but NOT necessary to be engaged. Hence, IMO this 

	> fits to a definition of a capability, albeit inherent at
runtime. 

	> 

	> PY>Well like I said, it is one interpretation of capability, 

	> something the service side can handle if the client side 

	> engages it. Per another interpretation, it is a requirement 

	> on the client to engage it, even though the client has the 

	> option not to engage it, as it is "optional". I tend to think 

	> of capability as something the provider side declares that it 

	> is capable of doing (like guaranteed under 10 msec. response 

	> time). All assertions that depend on the client (consumer) 

	> side doing something, fall in the "requirement" category from 

	> my perspective. Requirements can be optional or mandatory, 

	> based whether the consumer side must do it or not. 

	> Capabilities have no such client side impact. They are pure 

	> provider side declarations, which if the provider does not 

	> meet or deliver put the provider out of policy.

	> 

	>  

	> 

	> The marker to indicate that an interaction will take 10 

	> seconds response time is more of a property of the service. 

	> 

	> PY>Well we don't have anything called a "property" in 

	> WS-Policy. I consider it a capability; it is a 10msec 

	> response time guarantee. 

	> 

	>  

	> 

	> I do not consider this a capability that is selectively
engaged. 

	> 

	> PY>By my definition of capability, it may or may not be 

	> selective. It is what the provider declares it can deliver 

	> and if the provider does not deliver it, it is out of policy.

	> 

	> 

	> In essence, the service does not advertise that "hey I can 

	> response to you in 10 seconds, but you must do sth in order 

	> to get this kind of quality of service". It just says that 

	> you will get this behaviour. IMO, this is just an inherent 

	> property of the QoS, not a capability. 

	> 

	> PY>Well we clearly have different view points here. I see 

	> that as a clear declaration of capability (sure a QoS related 

	> one in this case).

	> 

	>  

	> 

	>  It is a requirement of the service to provide you this QoS. 

	> The burden is on the provider (or whomever) that advertises 

	> this assertion as it is a requirement on their part. Just 

	> like a marker that advertises whether the interactions with a 

	> service guarantees confidentiality ("we won't sell your 

	> information to third parties".). You may be able to take 

	> legal action if they do if they did not comply with the 

	> advertised policy which they advertise. The client does not 

	> do or no choice in altering the outcome, but it is just 

	> there. I agree that this expression of this category should 

	> be part of the WS-Policy assertions. I would not call this a 

	> capability however. In this case, the #2 is a requirement, 

	> but the requirement is on the provider where the client does 

	> not need to do anything. 

	> 

	>  

	> 

	> In the end it all boils down to what we mean by "capability" 

	> and whether we need a glossary to explain it. The MTOM 

	> category IMO is certainly NOT a requirement. 

	> 

	> PY>The specification states that a "policy assertion" 

	> identifies either a "requirement, or capability of a policy 

	> subject." And it does not define a capability to be an 

	> optional assertion, whereas the primer is giving that 

	> interpretation.  I don't think that is accurate explanation 

	> of what the spec states, as it stands now. It is certainly 

	> subject to interpretation and contention.  

	> 

	>  

	> 

	> I am not sure why you don't see MTOM category to be not a 

	> requirement? If there is no "optional" on the assertion that 

	> calls for engaging MTOM by the client, then * it is * a 

	> requirement on the client to use MTOM encoding on the 

	> messages it sends and expect to receive and handle MTOM 

	> encoded messages, is it not?

	> 

	>  

	> 

	> Lets see what others think. After we solidify the 

	> terminology, it is easy to fix the guidelines, primer, etc. 

	> 

	> PY> Yep, fine with me, We clearly need a concrete definition 

	> of requirement and capability in the spec, given the 

	> demonstarted scope for interpretation here.

	> 

	>  

	> 

	> Cheers,

	> 

	>  

	> 

	> --umit

	> 

	>  

	> 

	>  

	> 

	>  

	> 

	>      

	> 

	>     

	> ________________________________

	> 

	> 

	>     From: public-ws-policy-request@w3.org 

	> [mailto:public-ws-policy-request@w3.org] On Behalf Of Prasad
Yendluri

	>     Sent: Friday, Sep 22, 2006 12:18 PM

	>     To: Daniel Roth; Yalcinalp, Umit; public-ws-policy@w3.org

	>     Subject: RE: ISSUE 3564: Optional Assertions may not be 

	> usable in all cir cumstances 

	> 

	>     Dan, Maryann, Umit et. al,

	> 

	>      

	> 

	>     The spec defines  a policy assertion to be, " A policy 

	> assertion 

	> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2006/ws/policy/ws-pol

	> icy-framework.html#policy_assertion>  identifies a behavior 

	> that is a requirement or capability of a policy subject 

	> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2006/ws/policy/ws-pol

	> icy-framework.html#policy_subject> ."

	> 

	>      

	> 

	>     Where as the primer (best practices doc ?) clarifies, 

	> "Optional Policy assertions are assertions that express
capabilities."

	> 

	>      

	> 

	>     I tend to attributes two types of meaning to 

	> capabilities. (1) Things the provider can do if the requester 

	> tries to engage it (e.g use of MTOM/XOP encoding). That is, 

	> optional requirements, which is the interpretation that the 

	> primer has taken. However I can see another kind of 

	> capabilities (ii) capabilities e.g. a service declares it can 

	> do but there is no requirement on the client. For example, 

	> this service receives mail for xyz.com domain, but it also 

	> routes mail to domains other than xyz.com (serves as a mail 

	> gateway). Can a service declare that "capability" as an 

	> assertion? It is useful for the (mail) client to know so 

	> that, it can send mail addressed to other domains to this 

	> service. Another example is, a service that boasts a10 msec 

	> response time. My understanding is that declaration of 

	> capabilities such as these is a valid use of policy
assertions. 

	> 

	>      

	> 

	>     If so, the primer / best practices doc's interpretation 

	> of capability is incomplete and perhaps misleading? It would 

	> be useful to account for the use case #2 above also. 

	> 

	>      

	> 

	>     Honestly, I would like to call optional requirements 

	> just that (and not capabilities), as there may not be any 

	> capability implication to a service in general, if or not a 

	> client engages an optional requirement.  E.g. an optional 

	> requirement to follow-on an online Purchase Order request via 

	> hard-copy sent to a USPS address.

	> 

	>      

	> 

	>     Regards,

	> 

	>     Prasad

	> 

	>      

	> 

	>     -----Original Message-----

	>     From: public-ws-policy-request@w3.org 

	> [mailto:public-ws-policy-request@w3.org] On Behalf Of Daniel
Roth

	>     Sent: Friday, September 22, 2006 11:36 AM

	>     To: Yalcinalp, Umit; public-ws-policy@w3.org

	>     Subject: RE: ISSUE 3564: Optional Assertions may not be 

	> usable in all circumstances 

	> 

	>      

	> 

	>     I have reviewed the primer material on using 

	> wsp:Optional that Maryann and Umit proposed [1].  Other than 

	> a few minor edits (see attached) I think the proposal looks 

	> good.  The attached doc contains:

	> 

	>      

	> 

	>     - Various small editorial cleanups.

	> 

	>     - I believe the mtom assertion in Example 5-2 should be 

	> marked wsp:Optional="true" since it is referred to as an 

	> optional assertion.

	> 

	>     - The first bullet point seems to indicate that you 

	> must engage an optional behavior.  I think the intention was 

	> to state that if a provider decides to support an optional 

	> assertion it needs to have some way of figuring out which 

	> alternative is being used, either by looking at the wire or 

	> by some other means:

	> 

	>      

	> 

	>     NEW TEXT FOR BULLET #1:

	> 

	>     *       The engagement of the optional behavior must be 

	> explicit on the wire or through some other mechanism so that 

	> the provider can determine that the optional behavior is
engaged.

	> 

	>      

	> 

	>     I suggest that we accept Maryann and Umit's text with 

	> these minor changes as satisfying proposal option C for this
issue.

	> 

	>      

	> 

	>     Daniel Roth

	> 

	>      

	> 

	>     [1] 

	> http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/a

	>
tt-0054/ws-policy-assertionauthors-V1.html#optional-policy-assertion

	> 

	>      

	> 

	>     -----Original Message-----

	> 

	>     From: public-ws-policy-request@w3.org 

	> [mailto:public-ws-policy-request@w3.org] On Behalf Of Asir
Vedamuthu

	> 

	>     Sent: Friday, August 11, 2006 4:56 PM

	> 

	>     To: Yalcinalp, Umit; public-ws-policy@w3.org

	> 

	>     Subject: RE: ISSUE 3564: Optional Assertions may not be 

	> usable in all circumstances

	> 

	>      

	> 

	>      

	> 

	>     > In this case, a client sending a message

	> 

	>     > can not ensure that the outbound message will

	> 

	>     > be sent using MTOM optimization, by engaging the

	> 

	>     > capability as there are two alternatives.

	> 

	>      

	> 

	>     Providers and requestors rely on wire messages that 

	> conform to prescribed data formats and protocols for 

	> interoperability. If a requestor wants to signal to a 

	> provider that the requestor stack chose to engage MTOM code 

	> the requestor may indicate this by sending an MTOM encoded 

	> message. Another possibility is to send an HTTP Accept Header 

	> [1][2][3]. That is,

	> 

	>      

	> 

	>     Accept: application/soap+xml, Multipart/Related

	> 

	>      

	> 

	>     [1] 

	> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

	> 

	>     [2] http://www.w3.org/TR/soap12-part2/#httpmediatype

	> 

	>     [3] http://www.w3.org/TR/soap12-mtom/#xop-serialization

	> 

	>      

	> 

	>     This is protocol negotiation. This is not metadata.

	> 

	>      

	> 

	>     > MTOM and Reliability are good examples that

	> 

	>     > will be hindered if optionality is provided

	> 

	>      

	> 

	>     The above description covers the MTOM case. The 

	> behavior indicated by the Reliability assertion manifests on 

	> the wire as a Create Sequence message.

	> 

	>      

	> 

	>     > When a capability is only possible on message

	> 

	>     > level subjects and expressed to apply to

	> 

	>     > outbound messages only as optional assertions.

	> 

	>      

	> 

	>     If there are policies associated with a message policy 

	> subject for an outbound message, a provider is informing 

	> potential requestors that they must be open to engaging any 

	> of the policy alternatives in the effective policy of the 

	> message policy subject for an outbound message. It is up to 

	> the provider to make the choice on the outbound message. A 

	> provider may choose an alternative based on an inbound 

	> message (as defined by protocol bits - as illustrated above). 

	> The choice is still at the provider's discretion. Providers 

	> should consider this when expressing multiple alternatives on 

	> outbound messages. BTW, this is a good point to highlight in 

	> the Primer.

	> 

	>      

	> 

	>     Regards,

	> 

	>      

	> 

	>     Asir S Vedamuthu

	> 

	>     Microsoft Corporation

	> 

	>      

	> 

	>      

	> 

	>     ________________________________________

	> 

	>     From: public-ws-policy-request@w3.org 

	> [mailto:public-ws-policy-request@w3.org] On Behalf Of
Yalcinalp, Umit

	> 

	>     Sent: Wednesday, August 02, 2006 3:32 PM

	> 

	>     To: public-ws-policy@w3.org

	> 

	>     Subject: ISSUE 3564: Optional Assertions may not be 

	> usable in all circumstances

	> 

	>      

	> 

	>     Title: Optional Assertions may not be usable in all 

	> circumstances

	> 

	>     Description: Typically providers express capabilities 

	> by attaching assertions

	> 

	>     that are declared as "optional' on web service 

	> artifacts. Marking assertions

	> 

	>     optional allow representation of capabilities which may 

	> or may not be engaged

	> 

	>     although the capability is provided on the provider 

	> side. This is due to the

	> 

	>     fact that the presence of an optional assertion leads 

	> into two separate

	> 

	>     alternatives, one containing the assertion and one that 

	> does not.

	> 

	>     There are certain cases where the client of a web 

	> service can not ensure the

	> 

	>     engagement of an optional capability since the 

	> mechanism of choosing among the

	> 

	>     alternatives can not be ensured as there is no explicit 

	> mechanism to enable

	> 

	>     this. The following situations are detailed examples 

	> for this case:

	> 

	>     (a) When a capability may be assigned to an endpoint 

	> thus governing both

	> 

	>     inbound and outbound, but the incoming message can not 

	> be self describing to

	> 

	>     ensure the engagement of the capability.

	> 

	>     A typical example is to provide MTOM capability on an 

	> endpoint. Although the

	> 

	>     presence of an optional MTOM assertion indicates that 

	> MTOM optimization is

	> 

	>     possible, a client may not be able to engage MTOM. This 

	> situation will occur

	> 

	>     when the inbound message does not require optimization 

	> (i.e. may be a normal

	> 

	>     payload) and the outbound message may include an 

	> attachment and may provide

	> 

	>     MTOM optimization per WSDL definition. In this case, a 

	> client sending a message

	> 

	>     can not ensure that the outbound message will be sent 

	> using MTOM optimization,

	> 

	>     by engaging the capability as there are two alternatives.

	> 

	>     (b) When a capability is only possible on message level 

	> subjects and expressed

	> 

	>     to apply to outbound messages only as optional 

	> assertions. Again, the client

	> 

	>     can not engage the capability expressed by optional 

	> assertions, as the inbound

	> 

	>     messages will not include additional information to 

	> engage the capability

	> 

	>     expressed by the optional assertion that apply to 

	> outbound messages only.

	> 

	>     Note that case (a) the scoping may be apply to the 

	> endpoint, but the definition

	> 

	>     of messages may not allow the determination to be made 

	> based on the input

	> 

	>     message. In case (b), the granularity of attachment 

	> directly may prevent the

	> 

	>     determination. Therefore, there are two distinct cases.

	> 

	>     Without the presence of additional metadata exchange 

	> between the client and the

	> 

	>     provider, the engagement of optional assertions (more 

	> precisely the selection

	> 

	>     of one of the alternatives), engagement of a capability 

	> is only possible when

	> 

	>     the capability pertains to the input message and can be 

	> inferred. However, this

	> 

	>     is also a limited view, because on message level policy 

	> subjects, it is also

	> 

	>     not possible to disengage a capability on an outbound
message.

	> 

	>     Justification:

	> 

	>     Non-uniform treatment of optional assertions leads to 

	> interoperability problems

	> 

	>     as proven by the interop event [InteropPresentation]. 

	> It will lead providers to

	> 

	>     (1) assume either a particular treatment of optional 

	> assertions (always enforce

	> 

	>     or never use). Vendors may enforce an capability 

	> although an assertion is

	> 

	>     expressed to be optional. For example, if a client who 

	> is not capable of using

	> 

	>     MTOM were to use an endpoint with the capability and 

	> would always get MTOM

	> 

	>     optimized messages back from a service, the client can 

	> not use the service

	> 

	>     although the service "advertises" that MTOM is optional.

	> 

	>     (2) never use optional assertions. This is a limiting 

	> factor for being able to

	> 

	>     express capabilities that may be engaged but not 

	> required. MTOM and Reliability

	> 

	>     are good examples that will be hindered if optionality 

	> is provided.

	> 

	>     Proposal:

	> 

	>     There are several ways to solve this problem. Below 

	> here are three sketches.

	> 

	>     Complete proposals will need to be developed.

	> 

	>     (A) Provide additional binding specific mechanisms 

	> (such as specific SOAP

	> 

	>     headers) that allow clients to engage capabilities that 

	> may optionally apply to

	> 

	>     a message exchange.

	> 

	>     (B) b1. Disallow alternatives to exist for each subject 

	> after normalization as

	> 

	>     a design time constraint. Hence, disallow optionality 

	> at the endpoint level.

	> 

	>         b2. Disallow optionality completely. (Very much 

	> against this option)

	> 

	>     For b1, suggest in primer if a capability is to be 

	> expressed, always require

	> 

	>     the provider two separate endpoints, one that requires 

	> and one that does not in

	> 

	>     a WSDL. This is a design consideration that would need 

	> to be captured by

	> 

	>     primer, etc. but goes against the current design of the 

	> framework. I believe

	> 

	>     this is a very short term option and does not really 

	> yield to the usage of the

	> 

	>     framework to its fullest.

	> 

	>     C. Develop guidelines in primer about the utility of 

	> optionality and illustrate

	> 

	>     when optional assertions may require additional support 

	> from the environment

	> 

	>     (as in A)

	> 

	>     My preference:

	> 

	>     A, worst case C.

	> 

	>     Option B. has two major drawbacks and is only a short 

	> term solution until a

	> 

	>     full solution that addresses the framework intent is 

	> developed as mentioned in

	> 

	>     (A). Some of the techniques may go into the primer but 

	> optionality should not

	> 

	>     be disallowed. Further, this approach does not solve 

	> fine granular engagements

	> 

	>     of capabilities on a message level (see b)in the 

	> description). It separates the

	> 

	>     conceptional aspect (capability vs. constraint) from 

	> the framework and reduces

	> 

	>     WS-Policy to express only constraints.

	> 

	>     We should not hinder the framework at this stage and 

	> discourage optionality.

	> 

	>     [InteropPresentation]

	> 

	>     

	>
http://lists.w3.org/Archives/Public/public-ws-policy/2006Jul/0039.html

	> 

	>      

	> 

	>     ----------------------

	> 

	>     Dr. Umit Yalcinalp

	> 

	>     Architect

	> 

	>     NetWeaver Industry Standards

	> 

	>     SAP Labs, LLC

	> 

	>     Email: umit.yalcinalp@sap.com Tel: (650) 320-3095

	> 

	>     SDN:
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238

	> 

	>      

	> 

	> 
Received on Thursday, 28 September 2006 17:28:41 GMT

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