RE: Generic proposal for enganging MTOM in WSDL 2.0

Hi Jonathan!

> [this] goes against the style encouraged by WS-Policy specs, which is to use
> PolicyReference elements pointing to top-level policies.  This is
> illustrated in the primer [1].  I think this style is more readable and
> maintainable than embedding policy expressions inside WSDL operations, and
> seems to be the current practice on the ground.  

The flag isn't intended to be applied to any old WS-Policy rather one
which a publisher decides to craft in a way that's digestable 
by a non-WS-Policy processor.

> The profile of policy that
> the proposal below implies doesn't match this style, and therefore it's
> unlikely to be as broadly interoperable as we'd like. 

Is the risk that WS-Policy processors are unlikely to 
support the simple inline WS-Policy style?
 
Hi Arthur!

> [snip] it seems to me that you are proposing
> to profile WS-Policy. 

Oooh "profile" is such a loaded word.. I'm not saying to the world
"don't use WS-Policy", I'm saying to Canon "don't stick your MTOM assertions
firectly into WSDL, wrap them in a WS-Policy element and you'll interoperate
with WS-Policy processors" ..

> Wouldn't it be better if the WS-Policy WG defined a
> simple subset so that simple processors could implement it? This is like SVG
> Tiny. Maybe we need a WS-Policy Tiny? 

That would be one approach, but this isn't really for someone 
who is WS-Policy aware .. the flag could be applied to *any* wrapper
element, really. WS-Policy is a for-instance, we don't have to tie it down 
to one particular wrapper element QName. 

The aim of the proposal is to allow a publisher to write WSDL 2.0s which 
they can interoperate with WS-Policy aware processors, but allow them to indicate
to a consumer that they don't need to understand WS-Policy
language, that it's safe to just look for the precense of one or 
two XPaths to see if MTOM, etc are engaged.

Paul