You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by sn...@apache.org on 2002/11/09 01:09:52 UTC
cvs commit: xml-soap TODO
snichol 2002/11/08 16:09:52
Modified: . TODO
Log:
Updated and re-ordered.
Revision Changes Path
1.9 +56 -50 xml-soap/TODO
Index: TODO
===================================================================
RCS file: /home/cvs/xml-soap/TODO,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- TODO 11 Oct 2002 15:42:43 -0000 1.8
+++ TODO 9 Nov 2002 00:09:52 -0000 1.9
@@ -1,8 +1,63 @@
-Apache SOAP Project To-Do List:
+Apache SOAP Project To-Do List
+Updated: November 8, 2002
+
+All of the things listed in intro.html as not supported:
+========================================================
+
+- multiple encoding styles in the encodingStyle attribute
+ (see section 4.1.1 of the spec)
+
+- actor attribute and SOAP intermediaries (4.2.2)
+
+- complete mustUnderstand attribute behavior - only supports checking
+ for and rejecting requests that require mustUnderstand
+ checking (4.2.3)
+
+- element typing by having the name of the element bear a definite
+ relation to the type, that type then determinable from a schema,
+ except for elements named SOAP-ENC:Array (5.1 rule 2c)
+
+- deserialization of null values for XML schema types
+ that are mapped to primitive Java types (5.1 rule 9)
+
+- the complete set of XML schema simple types (5.2)
+
+- multi-dimensional arrays (5.4.2), arrays of arrays (5.4.2),
+ partially transmitted arrays (5.4.2.1), sparse arrays (5.4.2.2)
+
+- root attribute (5.6)
+
+- input/output and output parameters
General Wish List:
==================
+- allow config files to be resources so they can be packed in the war in a
+ portable manner
+
+- enhance the messaging sample by actually accessing elements from the
+ SOAP envelope within the service method
+
+- create a sample using envelope editors, an interesting possibility being the
+ use of XML digital signature
+
+- one-way messaging Microsoft style, in which the server responds with an
+ HTTP "202 Accepted" status upon receipt of the request *before* actually
+ invoking the method to handle it; this would be a deployment descriptor
+ option on the server
+
+- better isolate servlet container dependencies so that server code could
+ be used in non-servlet environments
+
+- support DIME and WS-Attachments
+
+- mirror Axis XML <--> Java mappings more closely
+
+- optional logging of requests and/or maintenance of request statistics
+
+- schema validation option with a way to specify schemas to possibly
+ validate against
+
- change the server side router to a regular class with a small servlet
to servlet-enable it. The idea is to enable the code to be used to
implement server-side support using other transports as well, such as
@@ -63,52 +118,3 @@
- add memory to the calculator demo where the memory is saved on the server
side. The purpose is to use a session scoped service and to see how to
implement the cookies stuff so that the right thing happens.
-
-- support DIME and WS-Attachments
-
-- mirror Axis XML <--> Java mappings more closely
-
-- optional logging of requests and/or maintenance of request statistics
-
-- follow HTTP redirects on the client
-
-- improve the messaging sample to actually read the envelope (as instruction
- to others on how to do this)
-
-- allow config files to be resources so they can be packed in the war in a
- portable manner
-
-- one-way messaging Microsoft style, in which the server responds with an
- HTTP "202 Accepted" status upon receipt of the request *before* actually
- invoking the method to handle it; this would be a deployment descriptor
- option on the server
-
-- schema validation option with a way to specify schemas to possibly
- validate against
-
-All of the things listed in intro.html as not supported:
-
-- multiple encoding styles in the encodingStyle attribute
- (see section 4.1.1 of the spec)
-
-- actor attribute and SOAP intermediaries (4.2.2)
-
-- complete mustUnderstand attribute behavior - only supports checking
- for and rejecting requests that require mustUnderstand
- checking (4.2.3)
-
-- element typing by having the name of the element bear a definite
- relation to the type, that type then determinable from a schema,
- except for elements named SOAP-ENC:Array (5.1 rule 2c)
-
-- deserialization of null values for XML schema types
- that are mapped to primitive Java types (5.1 rule 9)
-
-- the complete set of XML schema simple types (5.2)
-
-- multi-dimensional arrays (5.4.2), arrays of arrays (5.4.2),
- partially transmitted arrays (5.4.2.1), sparse arrays (5.4.2.2)
-
-- root attribute (5.6)
-
-- input/output and output parameters
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>