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

Re: AFTF requirements list with comments, pre-2003/01/28 telcon (revised)

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Fri, 31 Jan 2003 12:27:02 -0500
To: David Orchard <dorchard@bea.com>
Cc: xml-dist-app@w3.org
Message-id: <36331510-3541-11D7-85E9-0003937568DC@sun.com>

On Thursday, Jan 30, 2003, at 13:35 US/Eastern, David Orchard wrote:
>
> RNew. The specification should support streaming of parts, ie chunked
> encoding.  A sample scenario of this should also be provided.
>
Isn't chunking is a solution to streaming rather than a requirement ?

Marc.

>
>> -----Original Message-----
>> From: xml-dist-app-request@w3.org
>> [mailto:xml-dist-app-request@w3.org]On
>> Behalf Of Mark Jones
>> Sent: Wednesday, January 29, 2003 7:23 AM
>> To: xml-dist-app@w3.org
>> Subject: AFTF requirements list with comments, pre-2003/01/28 telcon
>> (revised)
>>
>>
>>
>> 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/2003J
>> an/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>
>>
>> <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>
>>
>>
>> * 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/2003J
>> an/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>
>>
>> <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>
>>
>
>
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Friday, 31 January 2003 12:26:38 GMT

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