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.


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

DR3. The specification must admit a reasonably time-efficient means of
     identifying parts.

DR4. The specification must use a reasonably space-efficient

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
      (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
Received on Monday, 13 January 2003 14:10:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:22 UTC