- 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
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 UTC