- From: <paul.downey@bt.com>
- Date: Wed, 6 Dec 2006 16:35:17 -0000
- To: <jonathan@wso2.com>, <ryman@ca.ibm.com>
- Cc: <www-ws-desc@w3.org>
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? > 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? > 5) Can be defined for multiple versions of Policy. as with the flag, which could be applied to non Policy elements .. > 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? > 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 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 16:35:32 UTC