- From: David Orchard <dorchard@bea.com>
- Date: Fri, 7 Feb 2003 21:32:14 -0800
- To: <jones@research.att.com>, <xml-dist-app@w3.org>
Could you point to the reasoning why my suggestion on requirement R6 was rejected? I can live without (and prefer to) relative URIs, but I have a tough time living without URI-References. And the question was asked about manifest functionality: An example of a manifest would be something like <part ref="part1"> <part ref="part2"> The typical manifest functionality, where the list of parts in the package are known ahead of time, or generated afterwards. I'm not yet sure whether I think that the type and length also should be in the manifest. As for whether they would be in a soap envelope or not, I would say that "it depends". I think we need some more scenarios to figure out where the possible places the manifest should ... manifest itself. I tend to think that it should be outside the soap envelope, so that there is a clean separation between the soap and attachment functionality. As to whether the WSCG should decide about WSDL relationship, it seems that ws-arch would be a logical place to go. Arch is responsible for making at least some recommendations about the technical content/scope of specifications and work in the w3c. Maybe ask ws-arch, and then if ws-arch says "yes" then ask CG if that's ok? Cheers, Dave > -----Original Message----- > From: xml-dist-app-request@w3.org > [mailto:xml-dist-app-request@w3.org]On > Behalf Of Mark Jones > Sent: Friday, February 07, 2003 11:42 AM > To: xml-dist-app@w3.org > Subject: AFTF requirements, post-2003/02/07 telcon > > > > AFTFers, > > This version of the requirements reflects discussion in the Friday, > 2003/02/07 AFTF meeting. > > Our current scorecard is: > 22 requirements agreed (R8, R9, R15, R24, R17, R1, > R2, R3, R4, R5, R13, R30, R21, R31, R22, R18, > R27, R29, R7, R6, R11, R26) > 1 requirement that needs clarification (DR28) > > R6, R11 and R26 were the most problematic of the > newly discussed requirements and have important > philosophical issues associated with them. > > --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 > > > ________________________________________________________________ > > > Concrete Attachment Feature Requirements > ---------------------------------------- > > The terminology used in this document is intended to be consistent > with that found in the SOAP 1.2 Abstract Feature specification > [http://www.w3.org/TR/2002/WD-soap12-af-20020814/]. > > > Considerations > -------------- > > * If existing packaging schemes (e.g., Multipart-MIME, DIME, ZIP, tar, > jar, etc.) meet the requirements, or represent sensible tradeoffs, > then the specification SHOULD use such existing schemes. > > * The specification should, where reasonably practical, be designed to > facilitate message construction, parsing, debugging, tracing, > implementation optimizations and other diagnostic activities. > > > 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 be conveniently describable by > languages such > as WSDL. > [WSDL should have enough extensibility to handle reasonable > new attachment specifications include ours. Our spec should > be reasonably describable by languages such as WSDL.] > > R24. The specification should include sample changes to WSDL > 1.2 and/or > extensions to WSDL. [Should this be decided by the WSCG?] > > R17. The specification must work with the SOAP 1.2 HTTP binding and > shouldn't unnecessarily preclude working with other bindings. > > > > Representation > -------------- > > R1. The specification must define a means to carry multiple data > parts. > > R2. The specification must define a means for parts to carry > arbitrary data, including non-XML data (e.g., binary data and XML > fragments). > > R3: The specification should support efficient implementation of: > a) parsing the physical representation to separate and > identify its > constituent parts. > b) programming systems which efficiently resolve a URI > to retrieve the > data (and metadata) comprising the corresponding part. > > R4. The specification should use a reasonably space-efficient > representation. > > R5. The representation should efficiently support the addition and > deletion of parts by intermediaries. > > R13. The specification must provide support for arbitrarily large > parts. > > R18. The specification must define a mapping between the attachment > representation and a standalone SOAP message. For > example, this may aid > down-level receivers that do not understand this specification. > > R27. The specification should support securing of messages and message > parts, such as use of encryption and signatures, in a simple > manner. If practical, WS-Security should be supported. > > R29. [This requirement engendered a lot of discussion and has > some significant ramifications for the Abstract Attachment > Specification and for the basic conception of the SOAP > message infoset.] > > (a) A message with all its parts, however separated physically, must > be representable as a single infoset. > > (b) A message with all its parts, however separated physically, must > be describable as a single XML element in an XML schema. > > > Metadata > -------- > > R21. The specification should provide convenient means for > extending the > metadata carried with a message. > > R31. The specification should provide convenient means for > extending the > metadata associated with individual parts. > > R22. The specification should provide a means by which any > or all parts > MAY be labeled with associated MIME types. (I.e. > applications sending a > message are not obligated to label parts with MIME > types, but the > specification must provide for carrying the MIME type > if provided.) > > R30. The specification must provide an optional facility for > specifying > part size in advance. > > > Reference to Parts > ------------------ > > R6. Each part must be named by an absolute URI. The normal mechanisms > of URI references may be employed to refer either to parts or to > fragments. > > This requirement does not resolve another important issue which > involves two competing views of the semantics of these URIs. > > One model is that any URI scheme can be used to name the parts. > For example, the use of an http scheme would imply web caching > semantics when resolving a URI reference. > > An alternative model is that there should be a chosen attachment > URI scheme (e.g. the CID scheme in SwA). One could still implement > a web caching semantics but would do so through the use of SOAP > headers which would specify the http-to-CID mapping and interact > with the URI resolver. > > > R7. 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. > > R11. The specification should not specify a particular physical > ordering of parts. > > In particular, this requirement was motivated by a use case in which > the primary (SOAP) part was not required to be the first part. > > Physical order is significant, and there are cases in which control > over physical order is important (for example, see R26). The issue > here is whether the specification should be as rigid as SwA in > insisting, for example, that the primary SOAP part be the first part. > > > R12. The primary (SOAP) message part should be readily > locatable/identifiable. > > > R26. The specification should support streaming of parts, i.e. chunked > encoding. > > We recognize use cases in which streaming, interleaving, chunking, > etc. are important. Assuming that physical part order is significant > and controllable, various packaging mechanisms would permit > application-level solutions. The WG needs to decide whether to > provide a more universal solution; if so, we need to collect enough > use cases to properly design such a scheme. > > > DR28. The specification may provide manifest functionality. > > David Orchard: Could you give us a concrete example of 'manifest' and > explain why it would or wouldn't go in the SOAP envelope? >
Received on Saturday, 8 February 2003 15:26:26 UTC