[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrf] issue 127 - : MUST use RAP?
+1 Frey’s Law: “Every 5 years the number of architecture components double and the ability to comprehend them halves” Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601 Ian Robinson <ian_robinson@uk. ibm.com> To wsrf@lists.oasis-open.org 08/05/2005 04:49 cc PM Subject [wsrf] issue 127 - : MUST use RAP? This pulic review issue states: Line 372 (and others) says, "The GetResourcePropertyDocument request message MUST follow the WS-Resource Access Pattern." I'm not clear what requirement this normative MUST imposes on the implementer. RFC 2119 says keywords "MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions). For example, they must not be used to try to impose a particular method on implementers where the method is not required for interoperability." I assume, then, that the requirement to follow the WS-Resource Access Pattern has something to do with interoperability. But the definition in WS-Resource isn't much help when it says, "An identifier of the resource MUST appear as part of any message to a WS-Resource to allow the WS-Resource to disambiguate the resource targeted by the message. We refer to this pattern of access as the 'WS-Resource Access Pattern'." Would it be possible to spell out more clearly what an implementer needs to do to satisfy the interop requirements of WS-RAP? Use of the WS-Resource access pattern is a requirement for interoperability but, since we went back to a single embodiment, the description of what WS-RAP implies now looks a little obtuse. I propose this issue be resolved by retaining the MUST in WSRF-RP and by re-establishing a little of the text we lost from WS-Resource when removing the embodiments. Specifically, replace the bullet at line 127 of WS-Resource with: · "An identifier of the resource MUST be represented in any reference to a WS-Resource and MUST appear as part of any message to a WS-Resource to allow the WS-Resource to disambiguate the resource targeted by the message. We refer to this pattern of access as the “WS-Resource Access Pattern” (WS-RAP). The precise location of the resource identifier in a message to a WS-Resource depends on how the identifier is represented in the WS-Resource reference used to access the WS-Resource and also on the transport-specific bindings used to serialize the message." and update the definition of WS-Resource reference to: "A WS-Resource reference (or just reference) is a construct through which a single WS-Resource can be accessed. It is represented by an endpoint reference, or more precisely an XML element whose type is, or is derived (by extension) from the complexType named EndpointReferenceType defined by the [WS-Addressing] specification. The address of the Web service endpoint part of the WS-Resource is contained in the wsa:Address element information item of the endpoint reference. The resource identifier MUST appear either in the contents of the wsa:ReferenceParameter element information item of the endpoint reference or embedded as part of the wsa:Address element information item of the endpoint reference. In a message that is conformant to the WS-Resource Access Pattern the resource identifier of the resource must appear in the message according to binding-specific rules outlined in WS-Addressing. For example, in the SOAP binding defined by WS-Addressing, the Web service endpoint address is contained in the wsa:Address element information item in the endpoint reference and appears in the message as the contents of the wsa:To SOAP header, and each direct child element information item (if any) of the wsa:ReferenceParameter element information item appears in the message as a separate SOAP header. For a given resource identifier there may be many references. The way two references are compared for equality is implementation-specific and not defined by this specification." Attached is a version of WS-Resource with change tracking to illustrate the changes: (See attached file: wsrf-ws_resource-1.2-spec-issue127.doc) Regards, Ian(See attached file: wsrf-ws_resource-1.2-spec-issue127.doc)
wsrf-ws_resource-1.2-spec-issue127.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]