David,
This won't work. If you don't use DuplicateElimination, and
the CPA says to always eliminate duplicates, then the message
will always be in error!
There can be a conflict with the CPA on the parameters that
can be perMessage, and we agreed that an error is sent
in case of conflict. That is the way it works at present.
The value of this error is that it would catch accidental
misconfiguration of the MSH (such as,
operator error in changing the
wrong property sheet value and so on.)
You may say that it is "redundant" to have something in the
message when there is a CPA that governs it. If that really
bothered you, then I think you would consider getting rid
of the parameter in the message all together. But, I think the
consensus was that some parameters were to be governed
by the message. While I think there are good reasons
to question making some of these parameters flexible,
in the interest of getting the 1.1 version stable,
let us just accept what has been decided.
Then, to avoid all the talk about "override,"
(and the subsequent jettison of the point of having an
agreement governing a business process collaboration)
we decided to split the difference and have a way to
have the CPA reflect either fixed or flexible values.
Why do we have to revisit this decision endlessly?
Dale Moberg