- From: FABLET Youenn <fablet@crf.canon.fr>
- Date: Mon, 17 Jun 2002 10:09:18 +0200
- To: Dale Moberg <dmoberg@cyclonecommerce.com>
- CC: Web Services Description mailing list <www-ws-desc@w3.org>, Jean-Jacques Moreau <moreau@crf.canon.fr>
> > >Dale> Hmmh +0.5. I guess I was already reading "message" as really >amounting to "dataset". Since real messages can often be individuated >by things like Message-ids, and have a lot of meta information >in headers and what not, they are not what wsdl:message defines >anyway. Real messages are still probably not quite the "bits on the >wire" >but are not far removed. So the element tag is misleading. Does >that matter? (Deducting .5 for the combination of previous uncertainty >combined with empathy for existing early implementers.) > True. Terms consistency between WSDL1.1 & 1.2 is good, misleading terms in WSDL should also be fixed. >Dale> Possibly +1 here also. Should we "define" in WSDL or instead >"refer" >or "declare" within WSDL, with MEPs defined elsewhere? > IMO we should refer to MEPS via an uri as proposed by Glen (reuse of the XMLP WG effort). >I assume wherever this occurs it would be toward the binding side of things, right? Bindings then are encodings plus MEP(s) plus transfer protocol details >plus eventually other stuff? > We should be able to specify which mep we want to apply on each operation. We have (at least) two options to add the mep information: - in the binding - in a new structure between the portType and the binding It will generate less changes to add the MEP info at the binding level (as an attribute of the binding element for instance), though we may loose more or less the genericity of the MEP. The main advantage of the second alternative is that we can map one (operation+mep) to different protocols. Its main disadvantage is that a WSDL file will become bigger with redundant information parts (the operation tag for instance is present in the portType and the binding and may also be rewritten in the new "mep" element). Youenn
Received on Monday, 17 June 2002 04:10:00 UTC