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: Jean-Jacques Moreau [mailto:[email protected]]
> Sent: Monday, December 11, 2006 1:16 AM
> To: Jonathan Marsh
> Cc: [email protected]; [email protected]; [email protected]; FABLET
> Youenn
> Subject: Re: Generic proposal for enganging MTOM in WSDL 2.0
> 
> I've come to think of Paul's proposal as: dynamic schema redefinition.
> I.e. "wsdli:simpleAssertions" is really saying the content of this node
> will be a sequence of terminal elements. This could be generalized to:
> "wdli:type='schemaElementRef'", meaning: the content of this node is
> really "schemaElementRef", whatever one told you earlier (possibly
> through an earlier schema reference for the document).

I don't think that's sufficient.  There's nothing about a dual policy
assertion/wsdl extension that limits the policy elements to terminals.  And
just saying it's a list of terminals doesn't convey the important semantics
- that the enclosed policy assertions have dual utility as a WSDL extension.

However, if that's all you want, you could instead write a schema for the
subset of Policy that you wanted, and point to that via a xsi:schemaLocation
attribute.  Problem solved?!

> A possible further generalization would be to add dynamic document
> filtering. I.e. "wdli:type='schemaElementRef'" would also mean: first,
> filter the content of the current node through the schema fragment at
> "schemaElementRef", then apply processing as if the node had only
> contained the filtered content (which would also solve the
> "wsdl:required" issue). Applied to a policy assertion, this would mean
> removing all compositors and leaving only assertions. Maybe I'm really
> XML schema here as a kind of XSLT processor. Probably I've stayed in
> Japan too long recently. ;-)

Hmmm, sounds like normalizing policy expressions to the normal form to me
[1] to me.  If your implementation can do that, you're closer to being a
conforming Policy processor, and maybe you don't need much of a subset at
all.  Add in a little policy reference indirection (also possible through
XPath) and you're there.  You don't need a completely general purpose
implementation, just one that is adequate to answer the question you want
answered - is MTOM supported, required, or not.  If indeed one could write a
single XPath that would answer this question, wouldn't that be sufficient to
declare Canon's implementation conformant to WS-Policy, supporting only the
MTOM policy assertion?

[1]
http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/#normal-form-for-poli
cy-expressions

> Regarding Asir's proposal, for the following property to be true:
>  > 2) No changes to specs at all!
> isn't there first a prerequisite that a policy processor *MAY* support
> only a subset of a declared policy expression? I.e. assertions and not
> compositors?

You mean, you'd like an official conformance level that blesses the subset?

> I can see merits in this new proposal. I'm a little hesitant though to
> use only primer examples. We've followed that path before with MTOM and
> now we're into this issue.

I don't the use of primer examples is significant in how we got here.

> JJ.
> 
> Jonathan Marsh wrote:
> > See below
> >
> > Jonathan Marsh - http://www.wso2.com -
> http://auburnmarshes.spaces.live.com
> >
> >
> >
> >> -----Original Message-----
> >> From: [email protected] [mailto:[email protected]]
> >> Sent: Wednesday, December 06, 2006 8:35 AM
> >> To: [email protected]; [email protected]
> >> Cc: [email protected]
> >> 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
> >>
> >
> >
> >