[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional"
5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
All the best, Ashok
From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
Sent: Wednesday, May 17, 2006 7:11 AM
To: Mark Little; ws-tx@lists.oasis-open.org
Subject: RE: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional"I had always believed that MAY, MAY NOT, SHOULD and SHOULD NOT were synonymous.RFC 2119 defines some of these key words as below. It does not define MAY and MAY NOTbut I assume these are equivalent to SHOULD and SHOULD NOT.1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.All the best, Ashok
From: Mark Little [mailto:mark.little@jboss.com]
Sent: Wednesday, May 17, 2006 6:49 AM
To: ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional"Do we really need to differentiate between SHOULD NOT and MAY? Seems to me that it would be more straightforward to go for either MUST, MUST NOT, and MAY, or MUST and MAY (c.f., the old CosTransactions::TransactionalObject approach). My preference would be for the former though.
If we look at the actual definitions of the words:
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
and
MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)
So although there are differences between SHOULD NOT and MAY in general, in this case (how WS-TX uses them), I'd feel more comfortable not straying into those vagueries where transaction propagation is concerned.
Mark.
Ian Robinson wrote:
>
>
>
> Monica,
> The 3 semantics that WS-AT is trying to represent are:
> a policy alternative that indicates that a tx context MUST be sent by a
> requester
> a policy alternative that indicates that a tx context SHOULD NOT be sent to
> a requester
> a policy alternative that indicates that a tx context MAY be sent to a
> requester.
>
> It is the TX domain that is defining presence of the policy assertion as
> "MUST send TX context". I don't understand why it is a misuse of Policy for
> the TX domain to define absence of this assertion as "SHOULD NOT send TX
> context". If this is a misuse of Policy, then how could the above 3
> alternatives be more properly expressed?
>
> Regards,
> Ian Robinson
>
>
>
>
> "Monica J.
> Martin"
> <Monica.Martin@Su To
> n.COM> Ram Jeyaraman
> Sent by: <Ram.Jeyaraman@microsoft.com>
> Monica.Martin@Sun cc
> .COM ws-tx@lists.oasis-open.org
> Subject
> Re: [ws-tx] Issue 045 - WS-AT:
> 08/05/2006 21:01 Meaning of "wsp:Optional"
>
>
>
>
>
>
>
>
>
>
>
>>> jeyaraman: It is possible for a client to infer MAY behavior based on
>>> the
>>> normalized policy alternatives (MUST and SHOULD NOT).
>>>
>>> For example, an operation may advertise a compact form of the AT policy
>>> assertion, such as:
>>>
>>> 1 <wsdl:operation name="TransferFunds" >
>>> 2 <wsp:Policy>
>>> 3 <wsat:ATAssertion wsp:optional="true" />
>>> 4 </wsp:Policy>
>>> 5 </wsdl:operation>
>>>
>>> A consumer may normalize the above policy expression (in compact form)
>>> into two policy alternatives: one with AT assertion (MUST) and another
>>> without it (SHOULD NOT). These two alternatives indicate that the AT
>>> behavior MAY be engaged.
>>>
>>> Hence, there is no need for a new attribute.
> mm1: Ram, let's separate Issue 45 [reference 1] concerns here:
>
> (1) Composition with WS-Policy and the use of the compact form
> (shortcut for expressing multiple alternatives)
> (2) WS-AT intended use of this optional attribute
>
> Clearly, choices made where wsat:ATAssertion wsp:Optional="true" is used
> or not, and if the policy is normalized, have impacts to implementation
> and interoperability.
>
> (1) In Section 3.2 of WS-Policy [reference 2]:
>
> "An assertion whose type is part of the policy's vocabulary but is
> not included in an alternative is explicitly prohibited by the
> alternative."
>
> Interpretation of the above WS-Policy text indicates that the WS-AT
> description of the compact shortcut, wsp:Optional="true", has to be the
> policy alternatives "MUST" and "MUST NOT" rather than the current
> specified alternatives of "MUST" and "SHOULD NOT". Otherwise, WS-AT is
> misusing WS-Policy.
>
> (2) WS-Policy does not prohibit postponing the selection of a final
> policy alternative, and this could be done with normalized forms, at the
> expense of a complex client interface. But, your simple example contains
> only a single assertion. In actual applications, a policy alternative
> can and likely will contain multiple types of policy assertions
> [reference 3].
> According to WS-Policy, a wsdl:binding/wsdl:operation can have a set of
> policy alternatives, one of which MUST be chosen. The final selection of
> one alternative could be delayed so long as they are acceptable to both
> client and service.
> However, it is unlikely that all types of assertions can support
> postponing the selection of a final policy alternative.
>
> In Section 5.2, WS-AT:
>
> "The absence of the assertion is interpreted to mean that a
> transaction SHOULD NOT be flowed inside a requester’s message."
>
> There are two points of view to the above stated behavior. If a
> requestor's message does flow a transaction that SHOULD NOT have been
> flowed, the current WS-AT specification leaves undefined how the service
> would handle such an unexpected transaction.
>
> The WS-AT specification does not state what happens when a policy
> assertion is not met. We should define that a service interpretation of
> the policy assertion takes precedence when the requestor flows a
> transaction context it should not have flowed. The service can either
> silently ignore the non-requested transaction context or it can fault on
> the mismatch between client and service interpretation of the wsat
> policy assertion.
>
> Thanks.
>
>
> ==========
> [1] Issue 45:
> http://lists.oasis-open.org/archives/ws-tx/200603/msg00168.html (on
> public site)
>
> [2] Reference: http://www.w3.org/Submission/WS-Policy/, see some of the
> sections important to this discussion:
> [start]
> p. 6, 3.1 Policy Assertion
> "A policy assertion identifies a behavior that is a requirement (or
> capability) of a policy subject."
>
> p. 6, 3.2 Policy Alternative
> "A policy alternative is a logical construct which represents a
> potentially empty collection of policy assertions. An alternative with
> zero assertions indicates no behaviors. An alternative with one or more
> assertions indicates behaviors implied by those, and only those
> assertions."...
>
> "An assertion whose type is part of the policy's vocabulary but is not
> included in an alternative is explicitly prohibited by the alternative."
>
> p. 7, 3.4 Web services
> "A requester may choose any alternative since each is a valid
> configuration for interaction with a service, but a requester MUST
> choose only a single alternative for an interaction with a service since
> each represents an alternative configuration."
>
> "A policy assertion is supported by a requester if and only if the
> requester satisfies the requirement (or accommodates the capability)
> corresponding to the assertion."
>
> p. 10, 4.3.1 Optional Policy Assertions
> "To indicate that a policy assertion is optional, this specification
> defines an attribute that is a syntactic shortcut for expressing policy
> alternatives with and without the assertion." [schema for Optional follows]
> "/Assertion/@wsp:Optional
> If true, the expression of the assertion is semantically equivalent to
> the following:
> <wsp:ExactlyOne>
> <wsp:All><Assertion ...> ... </Assertion> </wsp:All>
> <wsp:All />
> </wsp:ExactlyOne>
>
> If false, the expression of the assertion is semantically equivalent to
> the following:
> <wsp:ExactlyOne>
> <wsp:All><Assertion ...> ...</Assertion></wsp:All>
>
> Omitting this attribute is semantically equivalent to including it with
> a value of false." [an example follows with an actual assertion]
> [end]
>
> [3] According to WS-Policy, an alternative is a set of options
> (assertions).
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]