RE: i009 - mustIgnore rule for multiple To, ReplyTo, etc.

I took an action to provide a more concrete proposal for
option#3 for issue 9 - Cardinality of properties and their
values.

During the brief discussion at the Redmond F2F i was happy to
close down this issue by constraining the SOAP bindings, or even
the core, to allowing at most one instance of each of the EPR
values: (destination, source, reply, and fault).

However, DaveO sensibly asked why the "mustIgnore" rule couldn't
be used here. A sender could send as many ReplyTo etc values and
the receiver expecting would simply process the first and ignore
the rest.

The difficulty arises in identifying which of a repeated set of
'To' elements should be processed and which should be ignored
given SOAP header is an unordered bag of informational items.

Looking at other SOAP header specs such as WSS, the most common
method seems to be to place the items inside a container element
which has a Schema compositor of 'sequence'. Given the discussions
on i008, i can see that putting EPRs inside a 'ReplyTos', 'EPRs'
or even 'Addressing' wrapper element wouldn't be an attractive
proposition for this WG.

An alternative here would be to provide an attribute to each
EPR which could be used as a collation sequence or to identify
the purpose of each repeated EPR within an MEP, e.g.
<ReplyTo node='A'>.. <ReplyTo node='B'>, etc.
It's worth noting here that some MEPs which require more than
two nodes, e.g "in-out-in-out" will have to invent such a scheme
anyway, or use different names for additional EPRs - ReplyTo1,
ReplyTo2, etc *But* the purpose of my raising this issue was to
highlight the complexity and large number of subsequent issues
which would arise exploring such designs.

So option#3 of my proposal remains as at present: that the number
of wsa To, From, ReplyTo elements which may appear in a SOAP header
is unconstrained. The processing action taken to be taken
to be described by an optional processingStyle value, which could
map directly onto the MEP URI.

I have one minor suggestion which could enable the 'mustIgnore'
rule here: that if an EPR value is repeated and the processing
model is undefined or does not expect repeated values, that the
receiver is at liberty to select one (or as many as the MEP
requires) at random. I believe this is a similar statement to
the original proposal - that the default processing behaviour
is "undefined".


Paul

Previous proposal with the three options:
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0000.html


i009:
http://www.w3.org/2002/ws/addr/wd-issues/#i009

Received on Monday, 10 January 2005 15:38:39 UTC