[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 045 - WS-AT: Meaning of "wsp:Optional"
This is identified as WS-TX issue 045. Please ensure follow-ups have a subject line starting "Issue 045 - WS-AT: Meaning of "wsp:Optional ". -----Original Message----- From: Monica J Martin [mailto:Monica.Martin@Sun.COM] Sent: Friday, March 31, 2006 3:26 PM To: ws-tx@lists.oasis-open.org Cc: Ram Jeyaraman Subject: [ws-tx] New issue - WS-AT: Meaning of "wsp:Optional" Issue Name -- WS-AT: Meaning of "wsp:Optional" PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. The issues coordinators will notify the list when that has occurred. Target documents: WS-AT, CD 01, Section 5.2, lines 242-257. WS-AT schema (Note: This has not yet been reposted as CD 01). Artifact: (respectively) spec schema Draft: WS-AT CD 01 (spec) WS-AT schema Link to the document referenced (respectively): http://www.oasis-open.org/committees/download.php/17325/wstx-wsat-1.1-sp ec-cd-01.pdf (public: http://www.oasis-open.org/committees/download.php/17325/wstx-wsat-1.1-sp ec-cd-01.pdf) Note: Not yet posted as updated for CD 01. http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/16977/ws at.xsd (public: http://www.oasis-open.org/committees/download.php/16977/wsat.xsd) Section and .pdf line numbers: WS-AT CD 01, lines 242-257. Issue Type: Design Related Issues: None Issue Description: The use of "wsp:Optional" on /wsat:ATAssertion for conditionally flowing atomic transaction context in Section 5.2 in WS-AtomicTransaction (WS-AT) is fundamentally different from the use of "wsp:Optional" meaning "can be present or not". Issue Details: The "can be present or not" interpretation used in the WS-Policy [1] specification as implied by the description of normalization, where "optional" is described as "an attribute that is a syntactic shortcut for expressing policy alternatives with and without the assertion", and is found in Section 4.3, Compact Policy Expression (see specifically Section 4.3.1). The basic WS-Policy concept is that *one* set of alternatives is selected for a given interaction. So, using the WS-Policy [1] specified semantics, a client should either agree to always provide a transaction context or agree never to provide it. This implies a service contract where a transaction context is either always present or always absent. In contrast in WS-AT, the semantics are "if an atomic transaction context exist at the time the operation request is invoked, then flow it with the request". So the client has not agreed to provide a transaction context for all invocations of the operation request. This is equivalent to client and server agreeing to support multiple sets of alternatives in the same interaction. This deviates from standard WS-Policy semantics; for example, there is no way to say "in this interaction, we agree to use either AES encryption or 3DES encryption", with the server prepared to accept both from the same client in the same interaction, which is another variant of accepting multiple alternatives. What is the potential impact? A policy parser does not have a standard way to normalize a policy. The parser has to know whether "optional" means "if a concept is present, flow it with the request" or if it means "choose one alternative or the other". [2] Proposed Resolution: [specification] Replace use @wsp:Optional on /wsat:ATAssertion with a local attribute. Reason: Use a local attribute consistent with WS-AT semantics, which also simplifies normalization for a policy parser. Thus, this removes WS-AT usage of WS-Policy's wsp:Optional. Proposed rewording in Section 5.2 Normative Outline, lines 242-257. Change from: <wsat:ATAssertion [wsp:Optional="true"]? ... > ... </wsat:ATAssertion> The following describes additional, normative constraints on the outline listed above: /wsat:ATAssertion A policy assertion that specifies that an atomic transaction MUST be flowed inside a requester's message. From the perspective of the requester, the target service that processes the transaction MUST behave as if it had participated in the transaction. The transaction MUST be represented as a SOAP header in CoordinationContext format, as defined in WS-Coordination [WS-Coordination]. /wsat:ATAssertion/@wsp:Optional="true" Per WS-Policy [WS-Policy], this is compact notation for two policy alternatives, one with and one without the assertion. Presence of both policy alternatives indicates that the behavior indicated by the assertion is optional, such that an atomic transaction MAY be flowed inside a requester's message. The absence of the assertion is interpreted to mean that a transaction SHOULD NOT be flowed inside a requester's message. Change to: <wsat:ATAssertion [required="false"]? ... > ... </wsat:ATAssertion> The following describes additional, normative constraints on the outline listed above: /wsat:ATAssertion A policy assertion that specifies that an atomic transaction MUST be flowed inside a requester's message. From the perspective of the requester, the target service that processes the transaction MUST behave as if it had participated in the transaction. The transaction MUST be represented as a SOAP header in CoordinationContext format, as defined in WS-Coordination [WS-Coordination]. The absence of the assertion is interpreted to mean that a transaction SHOULD NOT be flowed inside a requester's message. /wsat:ATAssertion/@required="false" Presence of attribute @required with a value of "/false/" indicates that an atomic transaction MAY be flowed inside a requestor's message. [schema] Change from: <!-- Policy assertions --> <xsd:element name="ATAssertion"> <xsd:complexType> <xsd:sequence> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType> </xsd:element> Change to: <!-- Policy assertions --> <xsd:element name="ATAssertion"> <xsd:complexType> <xsd:sequence> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <!-- BEGIN ADD. Add an optional attribute. --> <xsd:attribute name="required" type="xsd:boolean"/> <!-- END ADD --> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType> </xsd:element> [end] [1] http://schemas.xmlsoap.org/ws/2004/09/policy/ [2] This supports our charter that the policy assertions be usable in the policy framework defined by WS-Policy rather than defining concepts that surround those functions. Charter located at http://www.oasis-open.org/committees/ws-tx/charter.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]