RE: Generic proposal for enganging MTOM in WSDL 2.0

The risk I saw is that you can't take an off-the-shelf WSDL with embedded
policy and simply add the new annotation and expect it to work with Canon's
implementation.  You'd have to do a fairly severe restructuring, losing the
maintainability provided by the indirection.

If that's not the goal, and one would instead be taking an off-the-shelf
WSDL with MTOM extension and adding WS-Policy, or crafting a WSDL from
scratch that would work with both, then this proposal makes more sense.

It is unfortunate that there will be two ways to express an extension - 
  <my:extension/>
and
  <foobar wsdli:simpleAssertions="true">
    <my:extension/>
  </foobar>

Are there any ambiguities with this?  Namely, what if I understand both
<foobar> and <my:extension>.  Does the processing of wsdli:simpleAssertions
turn off the "understanding" of foobar?  Another way to ask this is - what
does the component model look like?  Both from a foobar aware processor and
a my:extension processor.

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
 

> -----Original Message-----
> From: paul.downey@bt.com [mailto:paul.downey@bt.com]
> Sent: Wednesday, November 29, 2006 6:40 AM
> To: jonathan@wso2.com; ryman@ca.ibm.com
> Cc: www-ws-desc@w3.org
> Subject: 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

Received on Wednesday, 29 November 2006 23:54:28 UTC