CARVIEW |
Select Language
HTTP/2 200
date: Tue, 07 Oct 2025 19:25:51 GMT
content-type: text/html
content-encoding: gzip
last-modified: Thu, 20 Jul 2023 23:26:47 GMT
cache-control: max-age=2592000, public
expires: Thu, 06 Nov 2025 19:25:51 GMT
vary: Accept-Encoding
access-control-allow-origin: *
x-request-id: 98afc9684aa9a403
strict-transport-security: max-age=15552015; preload
x-frame-options: deny
x-xss-protection: 1; mode=block
cf-cache-status: MISS
set-cookie: __cf_bm=0kSIuJscVpY_cEeChW4AiZ5IkHopCvxTzLosWCKetgk-1759865151-1.0.1.1-ODkE5.KeoPqquWO6bq2Ychki6GAeaGKp5Qir6CiGlViyPomjzxt_9X8c3tqK7Ee.3m_7WWaywrMVNl4j1Y5hbSgb5DgJL6QWRzig2p3bXQ0; path=/; expires=Tue, 07-Oct-25 19:55:51 GMT; domain=.w3.org; HttpOnly; Secure; SameSite=None
server: cloudflare
cf-ray: 98afc9684aa9a403-BLR
alt-svc: h3=":443"; ma=86400
Issue with binding message references in the abstract component model from Roberto Chinnici on 2003-09-15 (www-ws-desc@w3.org from September 2003)
Issue with binding message references in the abstract component model
- From: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
- Date: Mon, 15 Sep 2003 15:48:37 -0700
- To: www-ws-desc@w3.org
- Message-id: <3F6641C5.1000909@sun.com>
Following the WG's decision to rename the "name" attribute of the wsdl:input and wsdl:output elements to "messageReference", and correspondingly to rename the {name} property of the message reference component to {messageReference}, we ended up with a mismatch between the interface-level message reference components and the binding-level ones. At the interface level, we have a message reference component with a {messageReference} property and a fault reference component with a {name} property. Although the latter needs more work to bring it into the new brave message-free world, I assume we won't modify its {name} property; unlike the old message reference component's {name}, the {name} of a fault reference component is indeed arbitrarily chosen by the WSDL author and it doesn't depend on the MEP in use. But at the binding level, we have just one component, the binding message reference component. Since it has a {name} property, you can readily see that there is a mismatch between it and its interface-level equivalents. Here are some visuals: <interface> <operation> <input messageReference="A" body="ns:foo"/> <output messageReference="B" body="ns:bar"/> <outfault name="MyFault" messages="ns:fault1 ns:fault2"/> </operation> </interface> <binding> <operation> <input name="A"/> <output name="B"/> <outfault name="MyFault"/> </operation> </binding> In order to fix this, I think that we should add a binding fault reference component (pretty much identical to the existing binding message reference component), and rename the {name} property of the binding message reference component to {messageReference}, so as to match the interface. Then the sample binding would become: <binding> <operation> <input messageReference="A"/> <output messageReference="B"/> <outfault name="MyFault"/> </operation> </binding> I'd also expect the messageReference attribute on the binding input element to be optional, just like for an interface operation's input. Roberto -- Roberto Chinnici Java Web Services Sun Microsystems, Inc. roberto.chinnici@sun.com
Received on Monday, 15 September 2003 18:47:25 UTC