- From: Mark Jones <jones@research.att.com>
- Date: Wed, 15 Jan 2003 12:10:13 -0500 (EST)
- To: xml-dist-app@w3.org
Here is another list of requirements following the ARTF (Attachment Requirements Task Force) telcon held from 11am-noon EST on Jan. 15, 2003. A couple of former draft requirements have been moved forward to "Considerations" instead. Those requirements marked "DR" have not yet been discussed in detail by the task force; those requirements marked "R" have achieved consensus within the task force. 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 ---------------------------------------- Considerations * The specification should not invent a packaging scheme. * The specification should aid debugging with simple tools. General Requirements R8. The specification must describe its relationship to the properties defined in Table 1 (att:SOAPMessage and att:SecondaryPartBag) in the SOAP 1.2 Attachment Feature specification. R9. The specification must describe its points of extensibility. R15. The specification should not unecessarily preclude convenient description by languages such as WSDL. 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 Wednesday, 15 January 2003 12:10:44 UTC