W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2003

new version of requirements following ARTF telcon

From: Mark Jones <jones@research.att.com>
Date: Mon, 13 Jan 2003 14:10:05 -0500 (EST)
Message-Id: <200301131910.OAA13007@bual.research.att.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:13 GMT