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

AFTF requirements, post-2003/02/03 telcon

From: Mark Jones <jones@research.att.com>
Date: Mon, 3 Feb 2003 15:20:30 -0500 (EST)
Message-Id: <200302032020.PAA23552@bual.research.att.com>
To: xml-dist-app@w3.org


This version of the requirements reflects discussion in the Monday,
2003/02/03 AFTF meeting.  A considerable amount of time was spent
discussing R29, which now has two subparts.  It raises larger issues
which need to be debated in their own right in the XMLP WG.

Our current scorecard is:
  19 requirements agreed (R8, R9, R15, R24, R17, R1,
         R2, R3, R4, R5, R13, R30, R21, R31, R22, R18,
	 R27, R29, R7)
  6 requirements not yet discussed (DR6, DR11,
         DR12, DR16, DR26, DR28)


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


* 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

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.


R1. The specification must define a means to carry multiple data

R2. The specification must define a means for parts to carry
    arbitrary data, including non-XML data (e.g., binary data and XML

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

R5. The representation should efficiently support the addition and
     deletion of parts by intermediaries.

R13. The specification must provide support for arbitrarily large

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.


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

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. 

<noah href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0037.html">
+1 except for the references to relative URI.  I think we want:  The 
specification must provide that each part be identified by an (at least 
one) absolute URI.

I think issues of relative should be above our level.  If some system 
(e.g. SOAP itself) wants to provide base URI and resolve relatives to 
absolute, that's fine, but we don't worry about that I think.  I would not 
want a part to be known at the deepest level as "../p".

<markJ href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0028.html">
We can consider your wording instead.

<davidO href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0044.html">
(alternate) DR6. The specification must permit parts to be identified by URIs or URI

This is similar to ChrisF's comment.

<noah href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0045.html">
I am a little surprised.  I would have thought that what we want is:

* The identity of each part is a URI (I.e. an absolute URI)

* References to parts are in the form of URI references (which are 
resolved through the usual mechanisms to yield the absolute URI).

David:  are you really saying that you want to allow "../a" as the 
identity of a part?  Thanks.

<davidO href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0047.html">
../a has nothing to do with URI References vs URIs.  ../a is allowed by URIs
and by URI references.  You might be thinking of absolute URIs however :-)

URI References are URIs that may have fragments.  Oh darn, we don't have a
term for a URI that has an absolutized portion that may have fragments.

<noah href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0048.html">
I stand corrected.  You're right of course.  Still, I would think that we 
want to follow web architecture.  As far as I know, that means that the 
resource which is a part should be identified by an absolute URI (not 
relative, NO fragment ID.)  References to the part as a whole should allow 
relative and absolute forms.  References within parts that have known 
media type should allow URI References, including fragment ID.

Bottom line:  a part is named by an absolute URI.  References are in the 
form of URI references, but Fragid is a reference within the part. 
Specifically, two references that differ only in their fragid must resolve 
to the same part.

Also:  on the phone call I suggested a requirement that the attachment 
implementation be capable of carrying a media type for each part.

David:  does this sound right?

<davidO href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0049.html">
Web architecture doesn't stipulate absolute URIs.  I would like to allow
frag ids, specifically so that parts could actually be fragments within an
xml document.  One example would be a soap with attachments package that
contains 2 xml documents, and the first refers to a part that is within the
2nd xml document.  I expect that in most cases, people would use absolute
URIs, but I can think of scenarios where they would want a fragment.  Let's
make this a bit more concrete.  I want to chunk a large xml document.  Say I
decide to split this into 2 documents. I could use an xinclude in the first
to refer to the 2nd, and I have an application that reads the first chunk,
then afterwards resolves the xinclude.  As XML requires a root note, the
XInclude has to point to a fragment in the 2nd document, specifically all
the children of the root node.

Now if a new version of XML allowed xml to not have a root node, like
external entities, this might be solved. :-)

I absolutely agree with carrying the media type.  Violently in fact.  These
documents, and parts, must be correctly self-describing.  Now that's web

<noah href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0050.html">
>>  I would like to allow frag ids, specifically 
>> so that parts could actually be fragments within an
>> xml document.  One example would be a soap with 
>> attachments package that contains 2 xml documents, 
>> and the first refers to a part that is within the
>> 2nd xml document. 

Hmm.  This is an interesting idea, and I can see the merits.  On the other 
hand, don't we then lose the ability for the parts themselves to have a 
MIME type and for fragments to reference within the parts?  I wonder 
whether that isn't the more important use case.  I'm nervous about trying 
to allow both at the same time.  Does the web even allow:  xxxx#a#b  to 
reference a piece of a part that is itself within an XML document? 

I think the design point for parts is only secondarily XML within XML, I 
think it's primarily non-XML data, and I think MIME types are the obvious 
web-compatible way to handle that.   I think it's important that 
attachments are just web resource (or at least representations of web 
resources) that happen to travel with the messages.  I'm not sure your 
proposal is compatible with that view.

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.

DR11. (a) The specification should permit an initial human readable
      (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... 

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

<noah href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0037.html">
Right.  I also think the notion of "initial" is fuzzy.  Is it within the 
first 100 bytes?  Is it no binary data between the start of message and 
this initial part (so you can use text tools to get that far).  Does it 
preclude interleaving?  I think this is too specific and we should drop 
<davidO href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0044.html">
preferred wording is (b)

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? 

<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
<noah href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0037.html">
+1 but suggests

(alternate) DR12.  The primary (SOAP) message part should be readily 

I think this correctly layers the packaging abstraction (part) from its 
use by SOAP.

<davidO href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0044.html">
(alternate) DR12. Any message parts should be readily locatable/indentifiable.

DR16. The part identifier scheme to be determined by sending

<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).  

<markJ href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0028.html">
URI is what I have in mind.

<noah href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0037.html">
No.  I think that URI schemes should be used according to their 
definition.  This should not be a round-about way of enabling the caching 
scenario (if that's what's intended.)  Cachcing can be enabled with a SOAP 
feature (mapping an HTTP: URI to a CID:, for example).  The part in the 
message is unlikely to be correcly id'd directly with an HTTP URI (unless 
we're doing lazy pull through an http network.)

<davidO href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0044.html">
DR26. The specification should support streaming of parts, ie chunked
encoding.  A sample scenario of this should also be provided.

<marcH href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0053.html">
Isn't chunking is a solution to streaming rather than a requirement ?

<noah href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0058.html">
Agreed.  Actually, I think it may be viewed as a solution to interleaved 
streams, in which more than one stream makes progress at a time, perhaps 
in a manner that's correlated at the application level (e.g. television 
frames with metadata about each interleaved.)  I've always been a bit 
nervous that SOAP isn't well engineered to facilitate this.  I think it 
basically didn't make the 80/20 cut.  I'm very much on the fence whether 
it's a good requrirement to adopt now, as I suspect that doing it only at 
the attachment level begs a lot of questions about the higher level 
abstraction supported (which is really your point, I think.) Thanks.

<davidO href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0044.html">
DR28. The specification may provide manifest functionality.
(needs clarification -- abstract?)
Received on Monday, 3 February 2003 15:21:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:22 UTC