- From: Mark Jones <jones@research.att.com>
- Date: Wed, 29 Jan 2003 10:04:37 -0500 (EST)
- To: xml-dist-app@w3.org
AFTFers,
Here is another version of our draft list. I've added in-line the
comments received so far on the requirements so we can more easily
consider the feedback we've gotten.
I've also appended a summary of three new draft requirements recently
proposed by Jeff Schlimmer (Microsoft) and commented on by Sanjiva and
John Barton.
--mark
________________________________________________________________
Concrete Attachment Feature Requirements
----------------------------------------
Considerations
--------------
* The specification should not invent a packaging scheme.
<barton href="//http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0027.html">
Perhaps I don't quite understand the meaning of "packaging scheme" but
the way I interpret this is "the ARTF is going to pick between SwA and
DIME", which isn't truly possible since neither are sound enough.
Perhaps you mean The specification should resemble existing packaging
schemes.
</barton>
* The specification should aid debugging with simple tools.
<chris href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0025.html">
This has me baffled. What is it that you have in mind in the way of
tools, and more specifically, are you suggesting that the
specification would define said tools or that the specification would
define a concrete binding that had as a design consideration that an
implementation would be inherently debuggable? Further, what manner of
"debugging" are we talking about here?
</chris>
<barton href="//http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0027.html">
I think this one was added at my suggestion. I would word it:
The specification should rely on plain ASCII headers.
Plain ASCII (no not internationalized) makes debugging message systems
considerably easier. Compare anyone's experience in working with HTTP on
the one hand and RPC/Jini/Corba on the other. Please note that ASCII does
not mean unformatted ASCII. Processing many small messages (~packet
size) would benefit from fixed formats.
</barton>
<markH href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0029.html">
I think there's a (perhaps not clearly made) distinction between
packaging scheme and attachment specification. My take on 'not invent a
packaging scheme' is that the attachment specification will use an
existing technology like MIME or DIME or ZIP (or tar or jar or ...) as
the underlying packaging technology rather than inventing everything
from the ground up. The attachment specification would describe how to
use the underlying packaging scheme for packaging SOAP messages and
attachments.
</markH>
<markJ href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0028.html">
John Barton suggested this one and his reply to your note
captures his intention.
</markJ>
General Requirements
--------------------
R8. The specification must describe its relationship to the
properties defined in Table 1 (att:SOAPMessage and
att:SecondaryPartBag) in the SOAP 1.2 Attachment Feature
specification.
R9. The specification must describe its points of extensibility.
R15. The specification should not unnecessarily preclude convenient
description by languages such as WSDL.
<chris href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0025.html">
Hmmm... Why wouldn't the specification provide a normative WSDL binding
extension mechanism? Afterall, what authority is better suited to
define the extension than that which specifies the concrete binding
itself?
Yes, I realize this is the XMLP WG and not the WSDL WG, but the WSDL
WG is not chartered with the specification of all WSDL extensions, just
the WSDL core syntax, processing model, extension points and framework.
It seems to me that not defining the WSDL binding extension for this
feature would be like the XMLP defering a schema definition of SOAP
to the XML Schema WG. Clearly, we would not do that, why would we defer
the definition of the WSDL?
</chris>
<jean-jacques href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0026.html">
If nothing else, this may be a timing issue. WSDL is evolving
rapidly; the SOAP 1.2 support is still in a state of flux; it
will take a little while before things are stable enough for the
ARTF so start dealing with this issue.
Also, it may well turn out that we need WSDL extensions for
dealing with attachments. It might make sense to built them into
the core.
</jean-jacques>
<markJ href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0028.html">
Jean-Jacques's reply touched on some of this. Noah suggested
the somewhat convoluted wording to try to convey the sense that WSDL
is still evolving and that it may need to stretch a bit also. (We
won't necessarily need the flexibility, but this gives us a litle
wiggle room.)
</markJ>
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.
<chris href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0025.html">
I think that rather than "identifying" this is intended to refer to
resolving or dereferencing, no? If not, then I guess I don't understand
the requirement's indended interpretation.
</chris>
<markJ href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0028.html">
"identifying" in this sense is more tied to finding parts in
the packaging -- byte lengths, boundary strings, etc.
</markJ>
DR4. The specification must use a reasonably space-efficient
representation.
DR5. The representation must efficiently support the addition and
deletion of parts.
<chris href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0025.html">
Hmmm... While it is clear that an implementation of the specification
would likely carry this requirement, it is less than clear that the
requirement is applicable to the specification itself. Further, one
would imagine that by this statement, it would be the intended to cover the
insertion or in-line deletion of parts, or had you only appending and
truncation in mind?
Again, it isn't clear that this requirement, as written is either
testable of a specification or relevant for a specification that is not
intended to be implementation-specific.
</chris>
<markJ href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0028.html">
The point here was to make the spec relatively friendly to
intermediaries that might need to modify the attachment bundle in
straightforward ways. (roughly resonant with the fact that insertions
and deletions of headers in a SOAP envelope are pretty straightforward
syntactically, for example).
</markJ>
DR13. The specification must provide support for large parts.
<chris href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0025.html">
And small ones as well one would imagine. How large? Arbitrarily
large? Just "pretty big", really, really large" or "incomprehensibly
large"? :)
What about parts who's size is not known at the time that
the serialization is begun?
</chris>
<markJ href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0028.html">
These points have been discussed briefly. This one needs more work.
</markJ>
<barton href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0030.html">
The reason for this kind of requirement is the dominant impact of I/O
and memory allocation on performance. For small messages, all
attachment scheme will be equal since CPUs are infinitely fast.
"Large" of course changes over time as hardware resources improve.
Design for messages between 1MB and 1GB. 5 years from now, when
this standard is in use, allocators can bite off 1MB but 1GB will likely
still call for disk. You can shift these numbers around, but they will
factor into the design: might as well discuss them explicitly.
In my opinion, parts whose size is not known should not be "attached"
to SOAP messages. Rather one should use messages to set up an
out of band stream mechanism.
</barton>
Reference to Parts
------------------
DR6. The specification must permit parts to be identified by URIs.
<chris href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0025.html">
Hmmm... I think that the specification should require that parts be
identified by URI, but that they may be identified using other means
as well. Of course, they could be identified by relative URI, not just
absolute URI.
</chris>
<markJ href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0028.html">
We can consider your wording instead.
</markJ>
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]
<chris href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0025.html">
Not sure I follow this...
</chris>
<markJ href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0028.html">
There was some sentiment for flexibility in part ordering -- for
example, having a text part preceeding even the SOAP message.
</markJ>
DR12. The SOAP message part should be readily locatable/identifiable.
<chris href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0025.html">
Should it not be the case that ALL parts be identified, identifiable?
What would make the SOAP part unique in this regard?
</chris>
<markJ href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0028.html">
We wanted to make sure if there were multiple SOAP message
parts that we could identify which one was the primary part and which
were attachments. This may be an issue if order were arbitrary, for
example.
</markJ>
DR16. The part identifier scheme to be determined by sending
application.
<chris href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0025.html">
"scheme" seems to imply "URI", but my guess is that it does not.
Again, I would strongly recommend that parts be identified by URI
(relative or absolute).
</chris>
<markJ href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0028.html">
URI is what I have in mind.
</markJ>
________________________________________________________________
New proposed requirements:
--------------------------
DR18. The specification must define a means to format messages for
down-level receivers that do not understand the specification.
<sanjiva href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0034.html">
How can any spec say something about those who don't understand the
spec? I'm confused.
</sanjiva>
<barton href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0033.html">
Maybe you can clarify this one Jeff...the way I read it, it sounds
impossible.
</barton>
DR19. The specification must enable efficient allocation of buffers by
receivers.
<sanjiva href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0034.html">
I'm again confused; while a statement like "this spec must be
implementable as efficiently as possible" is reasonable (and
motherhood-and-apple-pie IMO), speaking specifically about
buffer allocation seems rather pointed.
</sanjiva>
<barton href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0033.html">
This one motivates some of the other requirements but it implies that
the sender understand the receiver's memory allocation capabilities.
On one extreme the requirement could amount to "give the content
length of attachments up front", but at the other extreme it
could require the interleaving of parts to achieve a serialization
optimal for receiver processing.
As an example of the latter, the UPNP Printing folks worried about how
an extremely long XHTML doc with many inline images could be a printed
with one page buffer. While that may seem like an example far from
the one most SOAP folks consider, once you get to pipelined processing
of composed
SOAP services the differences begin to fade. These are cases you want
to be able to handle and they are cases that non-XML systems deal
with.
Of course the serialization of XHTML is well-defined. Serialization
for arbitrary receiver processing isn't. That makes this requirement
difficult to spell out absent information on the receiver buffer
capability. Consequently one might go for a requirement that asks the
spec. to allow attachments to be placed in the stream physically near
their first point of XML reference rather than getting into buffers.
That would pick up the critical use case without getting mired in an
open-ended problem.
</barton>
DR20. The specification must allow messages to be secured using the
mechanisms defined in WS-Security.
<sanjiva href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0034.html">
WS-Security only applies to SOAP envelopes. This requirement would
hence have the effect of precluding MIME/DIME style packaging ..
</sanjiva>
Received on Wednesday, 29 January 2003 10:05:09 UTC