issue 127 - : MUST use RAP?

[Ian Robinson <ian_robinson@uk.ibm.com>]

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

=?UTF-8?B?d3NyZi13c19yZXNvdXJjZS0xLjItc3BlYy1pc3N1ZTEyNy5kb2M=?=