- From: John J. Barton <John_Barton@hpl.hp.com>
- Date: Mon, 06 Jan 2003 09:54:16 -0800
- To: jones@research.att.com, xml-dist-app@w3.org
Mark, This is a good start. Some suggestions and comments: I would like to see one addition to your list: 0. The representation should aid debugging with simple tools. This is one of the most powerful reasons we are talking about XML messaging rather than binary messaging. Throwing this advantage out at the packaging layer makes no sense. -- The specification should allow the sending XML application to determine the part identifier. This allows SOAP messages to be ROMed for embedded systems. Its a bit hard to write this down because many people assume that the top of the stack is TCP, meaning that XML application is everything else. In practice the packaging software layers between the XML application and TCP, which is why we can talk about attachments separate from XML. The spec needs to recognize this split and allow the XML application to determine the URI. -- Performance analysis should assume modern hardware. Thus CPUs are fast and memory is cheap, but I/O transfers are slow and multiprocessing common. The specification needs to concentrate on how "large" messages (MB and GB) are handled. Optimizing the packaging of small messages will make no difference since setup and context switching latency will dominate over unpacking. (Actual measurements would be a great asset here.) -- I would urge the consideration of a MIME-receivable but fixed format ASCII encoded specification with part sizes preceding parts. This allows the receiver to unpack the message without dynamic memory allocation but keeps the headers in text. At 03:52 PM 1/3/2003 -0500, Mark Jones wrote: >Here's a stab at some initial requirements for the concrete attachment >spec(s). These are far from comprehensive I'm sure and may need some >tweaking, but hopefully it will get us going. > >--mark > >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 > >================================================================ > >SOAP Attachment Specification Requirements > >Representation > >1. The specification must define a means to carry multiple data parts. > >2. The specification must define a means for parts to carry > arbitrary data, including non-XML data (e.g., binary data and XML > fragments). > >3. The specification must admit a reasonably time-efficient > means of identifying parts. > >4. The specification must use a reasonably space-efficient > representation. > >5. The representation must efficiently support the addition and > deletion of parts. > > >Reference to Parts > >6. The specification must permit parts to be identified by URIs. > >7. 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. ______________________________________________________ John J. Barton email: John_Barton@hpl.hp.com http://www.hpl.hp.com/personal/John_Barton/index.htm MS 1U-17 Hewlett-Packard Labs 1501 Page Mill Road phone: (650)-236-2888 Palo Alto CA 94304-1126 FAX: (650)-857-5100
Received on Monday, 6 January 2003 12:54:22 UTC