Attachments Use Cases Summary

Here is the consolidated list of use cases for attachments that we have
been considering in XMLP WG. Please ref the UC numbers in the titles of any
emails.

++++++++++++++++++++++++++++++++++++++
========
UC-1, DEFERRED DISCUSSION UNTIL UC-9 UC-10 UC-11
A digital camera wishes to transmit image data over a wireless link using
SOAP to a remote server. The binary image data (non-XML) accompanies the
message. The digital camera represents a situation in which connections
from the receiver to the sender may not be permitted due to device
limitations or firewalls.

(This is http://www.w3.org/TR/2002/WD-ws-arch-scenarios-20020730/#S090.)

========
UC-2, IN PROGRESS.
Original: An application that uses URI to deref resources, and assumes the
only representation travels with the message

Reformulation: An application wishes to send a URI in a message, and the
receiver will dereference the URI. The sender chooses to "bundle" a
representation of the
resource in the message as well, so that the receiver may choose this
representation when it dereferences the URI. This is useful in cases when
the resource identified by the URI is inaccessible to the receiver, or the
receiver wants to avoid the overhead of dereferencing the resource over the
network, etc.

(Original from http://www.w3.org/2000/xp/Group/3/03/06-minutes.html.
Reformulation based on XMLP WG telcon IRC log from 17 Sept, 2003.)

========
UC-3, DROPPED, 10 Sept 2003.
An application that uses middleware/SOAP-stack to deref resources, and
assumes the only representation travels with the message.

========
UC-4, IN PROGRESS REFORMULATE AS A REQUIREMENT, 10 Sept 2003.
Digital camera wants to encrypt and/or sign the message and/or binary data.

========
UC-5, DROPPED, 10 Sept 2003.
Message with binary data successfully goes through SOAP 1.2 intermediary.

========
UC-6, IN PROGRESS.
Original: A representation is streamed upon receipt when sender and/or
receiver is constrained.

Reformulation: An application wants to send one big (but limited) piece of
binary data from the sender to the receiver. Either of the parties is
limited so it needs to be able to produce/consume the data in a streaming
fashion, i.e. the SOAP Envelope must be available with only the streamed
binary data being in process of transmission.

(Original from http://www.w3.org/2000/xp/Group/3/03/06-minutes.html.
Reformulation see thread at
http://lists.w3.org/Archives/Public/xml-dist-app/2003Sep/0043.html)

========
UC-7, DROPPED, 17 Sept 2003.
WSDL is is applicable where appropriate.

========
UC-8, DROPPED, 17 Sept 2003.
Representation is a digital camera produced VLOB.

========
UC-9, NOT YET CONSIDERED. "Undesirable Message Bloat"
An application wishes to send a SOAP message that contains a large
binary piece of data; e.g., a JPG image, binary executable or other
sizeable, non-textual data. For design reasons, this data cannot be
referenced externally, but must be transported with the message. Doing
so using base64Binary or similar encoding involves an unacceptable
message size, due to bandwidth, latency and/or storage requirements.

(From http://lists.w3.org/Archives/Public/xml-dist-app/2003Sep/0008.html)

========
UC-10, NOT YET CONSIDERED. "Undesirable Processing Overhead"
An application wishes to send a SOAP message that contains a large
binary piece of data; e.g., a JPG image, binary executable or other
sizeable, non-textual data. For design reasons, this data cannot be
referenced externally, but must be transported with the message. Doing
so using base64Binary or similar encoding involves unacceptable message
generation and/or parsing overhead, due to throughput requirements,
device limitations and/or other considerations.

(From http://lists.w3.org/Archives/Public/xml-dist-app/2003Sep/0008.html)

========
UC-11, NOT YET CONSIDERED. "Focused Intermediaries"
An intermediary wishes to process a large message, but only needs to
access a small section of the message. For efficient operation, it
needs to be able to construct the relevant parts of the message infoset
without actually reading and parsing the rest of the message, whilst
still being able to successfully forward the entire message.

(From http://lists.w3.org/Archives/Public/xml-dist-app/2003Sep/0008.html)
++++++++++++++++++++++++++++++++++++++

............................................
David C. Fallside, IBM
Data Management Standards
Tel 530.477.7169 (TL 544.9665)
fallside@us.ibm.com

Received on Wednesday, 17 September 2003 18:52:54 UTC