A different hybrid approach

Going purely syntactically, one would have to specify a regexp in order
to say "RM anon is allowed/prohibited."  This is the only use case I
know of so far for full regexps.  It shouldn't be hard to implement: the
tooling snarfs the WSDL (or policy), notes the restriction and complains
when someone tries to use a disallowed URI.

The problem is that the resulting error is not very informative.  It's
basically "your URI didn't look like <some regexp>" and not "you tried
to use RM anon.".  It's also better to try to catch errors sooner, and
it would suck to have to grovel through the WSDL (or policy), recognize
a magic regexp for RM Anon (and hope that someone didn't put in an
equivalent one differently spelled), all to figure out whether RM Anon
is allowed.

A better approach is to make AddressConstraint extensible, like pretty
much everything else.  WS-RX would integrate with this by contributing a
"RM anon" extension attribute and saying that it refers to RM anon URI
as described in section 3.10.  So you would see something like

<wsaw:AddressConstraint propertyName="wsa:ReplyTo" wsrm:anon="something
arbitrary"/>

Tooling can then see this and know for sure that MakeConnection is
allowed.  The division of labor is: RX (or whatever other spec)
specifies what its special URI look like and mean.  We provide a means
of saying where they can and can't be used.

OTOH, I'm still wondering if it might be simplest of all for WS-RX to
define an utterance for "MakeConnection spoken here" and be done with it
(in which case CR33 can be Gudged).

Received on Tuesday, 31 October 2006 07:06:35 UTC