W3C home > Mailing lists > Public > public-ws-addressing-comments@w3.org > May 2005

Comments on WS-A Core

From: Nilo Mitra (TX/EUS) <nilo.mitra@ericsson.com>
Date: Wed, 11 May 2005 10:11:26 -0500
Message-ID: <77BEF8ACD6CB1B4DA605D9D9CF554AEB0AE80A3C@eamrcnt727.exu.ericsson.se>
To: public-ws-addressing-comments@w3.org

I have the following comments on WS-A Core (http://www.w3.org/TR/2005/WD-ws-addr-core-20050331

Comment 1
=========
[editorial]

In the Introduction and Example 1-1 of Core, the term "message information headers" and "message information header blocks" , respectively, are used. This should be changed to "message addressing header...." in both places.

Comment 2
=========
[editorial]

Section 3, definition of [message id] says "...The value of this property is an opaque IRI whose interpretation beyond equivalence is not defined in this specification.....". The word "opaque" is not needed and should be deleted. (There was another instance where such a use of "opaque" was removed. This instance appears to have been missed, and should be removed for the same reasons.)

Comment 3
=========

Section 2.1 uses the expression "consuming applications" in two places in connection with the opacity and use of, respectively, reference parameters and metadata. This word "consuming" can be ambiguous and/or confusing. It seems that the the intention is that the word "consuming application" refers to an entity which recieves an EPR and uses it to invoke a Web Service. However the target Web Service, in turn, "consumes" some of the data implied by the RefPars and metadata. Thus, it seems that the expression "consuming application" could equally well apply to a user (sender) of a WS request (using EPRs and WS-A) as well as the target Web Service itself.

Note that section 4 (first sentence) describes users of EPRs as being of at least three types: "Users of WS-Addressing and EPRs (i.e., entities creating, consuming or receiving Message Addressing Properties and EPRs)...etc.". Here again, the distinction between "consuming" and "receiving" is ambiguous, as a potential client for a Web Service can be both a "consumer" (in the sense of section 2.1) when it receives an EPR for the target WS, as well as a "receiver".

My proposal is as follows:

In section 2.1, replace(unchanged text not provided for clarity):

"[reference parameters] : xs:any (0..unbounded). 
..... Reference parameters are also provided by the issuer of the endpoint reference and are otherwise assumed to be opaque to consuming applications. ........"

with

"[reference parameters] : xs:any (0..unbounded). 
..... Reference parameters are also provided by the issuer of the endpoint reference and are otherwise assumed to be opaque to an entity that uses this reference to invoke a Web Service. ........"

and, next, replace

"[metadata] : xsd:any (0..unbounded)
...... Metadata may be included in an endpoint reference to facilitate easier processing by the consuming application, or because the metadata was dynamically generated.
......."

with

"[metadata] : xsd:any (0..unbounded)
...... Metadata may be included in an endpoint reference to facilitate easier processing by the entity that uses this reference to invoke a Web Service, or because the metadata was dynamically generated.
......."

Comment 4
=========
[editorial]

The text in section 3 regarding the [relationship] and [reference parameter] properties uses the expression "...the following well-known URI...". Surely "well-known" is an exaggeration. I propose that for both these instances, the word "well-known" be replaced with "pre-defined" or "standardized".

Comment 5
=========

In section 3, the "unspecified message" and "anonymous" destination property values have the path segments ".../id/..." and ".../role/..." (changed to ".../address/..." per resolution of LC64 item13) for their "well-known" URIs. For some reason the pre-defined (but not well-known? ;-)) "reply" URI does not include any additional path segment. Why not? Conversely, are the path segments ../id/.. and ../role/..( or ../address/..) needed?

If one is included for "reply", some suggestions are ".../type/reply" or ".../message/reply".

Comment6
========

In section 3, why is the pre-defined [action] property value of "http://www.w3.org/@@@@/@@/addressing/fault" (defined in WS-A SOAP Binding section 5) not included here, just like all the other pre-defined values for various properties?

Proposed text (additions shown between <<>>):

"[action] : IRI (mandatory)
An identifier that uniquely identifies the semantics implied by this message.

It is RECOMMENDED that the value of the [action] property is an IRI identifying an input, output, or fault message within a WSDL port type. An action may be explicitly or implicitly associated with the corresponding WSDL definition. Web Services Addressing 1.0 - WSDL Binding[WS-Addressing-WSDL] describes the mechanisms of association.

<<A pre-defined [action] property value "http://www.w3.org/@@@@/@@/addressing/fault" is used when the reply message conveys a fault.>>"


Comment 7
=========

Why is there not a section "Formulating a Request message" equivalent to section 3.2 "Formulating a Reply message". The existing example 3-1 could be used, together with appropriate text, as content for such a section.

Thanks,
Nilo

Nilo Mitra
Ericsson, Inc.
desk: +1 212-843-8451
mobile: +1 516-476-7427 
Received on Wednesday, 11 May 2005 15:11:43 GMT

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