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).

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. ;-)

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?

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.

JJ.

Jonathan Marsh wrote:
> 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 Monday, 11 December 2006 09:16:20 UTC