RE: Generic proposal for enganging MTOM in WSDL 2.0

See below

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, December 06, 2006 8:35 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
> 
> Thanks Jonathan for writing this up
> 
> > Advantages:
> > 1) No new syntax needed.
> > 2) No changes to specs at all!
> > 3) Profile can be processed by a fully conformant WS-Policy processor.
> 
> wouldn't that be the case for the extension attribute?

Yes, that's a benefit of either proposal.

> > 4) Obviates need to describe the interaction of wsdli:simpleAssertions
> and
> > wsdl:required.
> 
> doesn't WS-Policy have the same issue?
> is there anything we can reference / reuse?

My concern was if one encountered:

<foo wsdl:required="true" wsdli:simpleAssertions="true">...</>

Wsdl:required says if you don't understand foo, you don't know the meaning
of the parent component.  Wsdli:simpleAssertions says you can treat the
embedded elements as direct WSDL extensions, even if you don't understand
foo.  The interaction between these two assertions of what must be
understood might be complex.  The simple composition of these features
means, I think, "you don't understand foo and thus you don't understand
foo's parent, so any processing of the extension, including the parts
indicated as potentially useful through wsdli:simpleAssertions, is outside
conformance of the spec."

We might instead want to say "wsdli:simpleAssertions trumps
wsdl:required="true", and thus wsdl:required values are ignored."  Or you
could say "You cannot use wsdl:required=true with wsdli:simpleAssertions.

In any case it's kind of messy, and I think Asir's proposal solves this by
eliminating the two constructs.  A client honors wsdl:required
independently.  For instance, a WSDL using the Canon profile would need to
have wsdl:required=true if any of the enclosed assertions are
wsdl:required=true (otherwise they're masked by implementations ignoring
wsp:Policy.)

> > 5) Can be defined for multiple versions of Policy.
> 
> as with the flag, which could be applied to non Policy elements ..

Yes, but it seems safer to identify specifically which elements have this
behavior, rather than a generic facility that might have uncomfortable
interactions with other elements.  For instance, other than a policy
framework, specifically designed to have assertions that are in turn
specifically design to do double duty as WSDL extensions, can you imagine
another useful purpose for the extension?  Especially if there are
interactions with wsdl:required, I can imagine malign purposes more easily
than benign ones.

> > 6) Supports any assertions supported by the implementation (just like
> > WS-Policy.)  This includes a possible future version of an MTOM
> assertion.
> 
> > 7) Isn't open to unintended side-effects (what evil uses could
> > wsdli:simpleAssertions be put to?)
> 
> Oh, probably no more evil than WS-Policy :-)
> but point taken.
> 
> > Disadvantages;
> > 1) Doesn't provide any standards status to such a profile.
> 
> we could add a non-normative example?

A primer example showing such a profile, perhaps?  ;-)

> > 2) Doesn't provide any machine-readable indication that the profile is
> in
> > use.
> 
> Machines could check no child elements from the wsp: namespace exist
> when looking for an assertion, something like:
> 
> ./wsp:Policy[not(wsp:*)]/wsoma:OptimizedMimeSerialization

Yeah, maybe we don't need an indication in the document that it conforms to
a profile, since you've demonstrated it's easy to check that oneself.

> FWIW I much prefer Asir's proposal - I'd like to see it cited as
> an example, but this is Canon's use-case ..
> 
> Paul

Received on Wednesday, 6 December 2006 18:06:29 UTC