- 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