- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 2 Apr 2002 10:53:46 -0800
- To: Jacek Kopecky <jacek@systinet.com>
- Cc: Glen Daniels <gdaniels@macromedia.com>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
IMHO more than nice to have. On Tuesday, April 2, 2002, at 08:36 AM, Jacek Kopecky wrote: > Glen, I agree this will be nice to have. 8-) > +1 > > Jacek Kopecky > > Senior Architect, Systinet (formerly Idoox) > http://www.systinet.com/ > > > > On Thu, 28 Mar 2002, Glen Daniels wrote: > >> >> Good day, all! >> >> Many moons ago, Paul Denning, David Clay, and myself took an action to >> start writing up a "module template" to essentially describe the >> framework for writing a SOAP 1.2 extension. For various reasons, this >> work fell by the wayside, but I note that we haven't come back to it >> or replaced it with anything else. >> >> I think it's critical that we have some section somewhere offering >> some guidance as to how to do this, since this is ostensibly going to >> be one of the major extensibility mechanisms by which a lot of people >> build on the platform we are creating. >> >> At a minimum, I would think such a section would indicate that a SOAP >> extension spec/module: >> >> * MUST identify itself with a URI (this becomes really critical when >> trying to describe services with something like WSDL, or when doing >> negotiation with an unknown party) >> >> * MUST clearly specify the content and semantics of the header blocks >> used to implement the behavior in question >> >> * MUST clearly specify any known interactions with other extensions in >> terms of semantics or sequence (for instance "this encryption >> extension will encrypt the contents of the body. On the receiving >> end, it MUST run before other extensions which rely on the unencrypted >> contents of the body.") >> >> * MAY indicate that the extension functions as an implementation of a >> SOAP feature as defined in sec 3 of part 1. In this case, the spec >> must also clearly specify the relationships (if appropriate) between >> any abstract properties defined in the feature spec (as described in >> sec 5 of part 2) and concrete instantiations in the SOAP envelope >> >> * SHOULD have a well-defined name of EITHER "SOAP extension" OR >> "module" :) >> >> I would be happy to take up some of the work on this again, but I'd >> like to bring it before the group as a whole as what I perceive to be >> a serious hole in the specs at the moment. Comments/discussion >> appreciated. >> >> Thanks, >> --Glen >> > > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 2 April 2002 13:53:48 UTC