RE: AFTF requirements, post-2003/02/07 telcon

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