W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

Re: New (?) issue : SOAP module specifications

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 2 Apr 2002 10:53:46 -0800
Cc: Glen Daniels <gdaniels@macromedia.com>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
To: Jacek Kopecky <jacek@systinet.com>
Message-Id: <F67A0FE2-466A-11D6-8ECB-000A27836A68@mnot.net>

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
Received on Tuesday, 2 April 2002 13:53:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:19 UTC