i009 Cardinality of properties and their values

Title:

"Cardinality of properties and their values"

Description:

Some properties, e.g., ReplyTo, only allow one EPR as a value, when it
may make sense to have multiple values; e.g., sending to many people.
Also, some people might want to send multiple instances in the same
message, e.g., multiple ReplyTo headers. Should this be disallowed?

Target:

Core, SOAP Bindings


Justification:

The charter [1] Scope #1 cites "a URI for destination address"
(singular) whilst scope#4 describes "subsequent destinations" (plural).
However the charter puts out of scope "new WSDL MEPs, composition of
MEPs, or interaction patterns, such as pub-sub, callback or notification
mechanisms".

This indicates that whilst addressing may be used in message exchanges
with more than one message destination, it is firmly out of scope for
this working group to define such message exchange patterns or how they
should be processed.

We are also chartered to refine the WS-Addressing member submission
which restricts the cardinality of message informational headers such as
destination, source, reply, fault, action and message id to be at most
one instance per message [2].

Allowing properties with a cardinality of greater than one introduces
several issues surrounding how the list should be processed, such as:

1) order (precedence) - is this important?
2) quantification (how much more desirable is address A over B?)
3) composition (send to at most one-of these,
      send here but not there, etc)
4) recovery following failures

It's easy to imagine a list of To addresses, for example, being used in
a multitude of simple to complex scenarios:

1) distribution lists (send to all, ignore failures)
2) load balancing (round-robin)
3) fail-over (attempt each alternate address in turn)
4) statistical (send to 5 random people out of these 100)
5) policy driven (send fastest weekdays, cheapest weekends)
6) combinations of the above
etc

So defining how a list of properties introduces processing issues which
are likely to be a very time consuming activity for this WG.

Defining a processing model for a list of properties could preclude such
a list being used in the future for unforeseen purposes.



Proposal:

Following a suggestion from Marc Hadley [3] i propose that the core
specification does nothing to preclude more than one of each of the
message informational headers (destination, source, reply, and fault)
from appearing more than once inside a single message.

However the SOAP bindings constrain the maximum occurrence of each of
these message informational headers to be at most one.

I further propose that the core specification has a single
'processingStyle' URI value which may be used to define the processing
model employed should multiple informational items be included in a
message. The processingStyle should not be exposed in our SOAP bindings
and by default be a value indicating "undefined behaviour".

[*] Issue 9:
http://www.w3.org/2002/ws/addr/wd-issues/#i009


[1] Charter:
http://www.w3.org/2004/09/wsa-charter.html


[2] WS-Addressing member submission:
http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/


[3] Discussion from the 3 Nov Telcon:
http://www.w3.org/2002/ws/addr/4/11/03-ws-addr-minutes.html#item03

Received on Friday, 12 November 2004 15:41:13 UTC