- From: Mark Jones <jones@research.att.com>
- Date: Mon, 13 Jan 2003 14:10:05 -0500 (EST)
- To: xml-dist-app@w3.org
Here is another rough list of requirements following the ARTF (Attachment Requirements Task Force) telcon held from noon-1pm EST on Jan. 13, 2003. I have added the designation DR in front of the requirement numbers to emphasize their "draft requirement" status. Mark A. Jones AT&T Labs -- Strategic Standards Division Shannon Laboratory Room 2A02 180 Park Ave. Florham Park, NJ 07932-0971 email: jones@research.att.com phone: (973) 360-8326 fax: (973) 236-6453 ================================================================ Concrete Attachment Feature Requirements ---------------------------------------- General Requirements DR8. The specification must describe its relationship to the SOAP message from the infoset perspective. DR9. The specification must describe its points of extensibility. DR10. The specification should not invent a new packaging scheme. DR14. The specification should aid debugging with simple tools. DR15. The specification should not preclude WSD description. DR17. The specification must work with the SOAP 1.2 HTTP binding and with as many other bindings as possible. Representation DR1. The specification must define a means to carry multiple data parts. DR2. The specification must define a means for parts to carry arbitrary data, including non-XML data (e.g., binary data and XML fragments). DR3. The specification must admit a reasonably time-efficient means of identifying parts. DR4. The specification must use a reasonably space-efficient representation. DR5. The representation must efficiently support the addition and deletion of parts. DR13. The specification must provide support for large parts. Reference to Parts DR6. The specification must permit parts to be identified by URIs. DR7. The URI identification scheme must be robust under the addition and deletion of parts -- i.e., it must not require that URIs to other parts be altered, it must be relatively easy to avoid URI conflicts, etc. DR11. (a) The specification should permit an initial human readable part. (b) The specification should not specify a particular ordering of parts. [still noodling on which version to prefer] DR12. The SOAP message part should be readily locatable/indentifiable. DR16. The part identifier scheme to be detremined by sending application.
Received on Monday, 13 January 2003 14:10:37 UTC