Re: AFTF requirements, pre-2003/01/31 telcon

"Martin Gudgin" <mgudgin@microsoft.com> writes:
> 
> We would like to add another DR for discussion. This is essentially a
> rewording of my earlier infoset related requirement in concrete form. I
> will still be submitting a comment on the abstract feature spec.
> 
> DRXX - A message with all its parts, however separated physically, must
> be representable as a single infoset and describable as a single XML
> element in an XML schema.

I have a concern with this proposed requirement.  First of all, I think it 
is really proposing a change to the SOAP 1.2 Attachment Feature WD [1], 
and not directly to the implementations for which we are gathering 
requirements.   [1] is fairly clear that attachments are to be named with 
URIs and accessed using the normal mechanisms of the web (though the 
actual resolution of the URIs, such as CID:, is presumably provided by the 
concrete embodiment of the feature in DIME, S+A or whatever.)

Furthermore, I prefer the status quo in [1].  I think the sorts of 
information we are trying to carry are best typed with MIME types;  I 
believe that the URIs that refer to those attachments fit comfortably into 
the Envelope infoset (as xsd:anyURI elements and/or attributes), but that 
the resource representations themselves do not.  I want to be able to be 
able to say:  "this part is of type image/gif".   Indeed, I would propose 
(I think I did on one of our telcons):

DRZZ:  It must be possible to associate a MIME type with any or all of the 
parts in a message.

This too, by the way, should perhaps be reflected more clearly in [1], in 
addition to being reflected in the requirements we are developing for 
concrete implementations.

To restate the position I've stated before:

I think we have a pretty good data model for attachments, and it's the Web 
model not an XML infoset.  The XML Infoset is the SOAP envelope.  It can, 
using the usual mechanisms of the Web, make references to resources using 
URIs.  Some of those resources (or representations of them) will be 
physically packaged with the message, and those we call attachments.  In 
the cases of interest (as opposed to mailto: URIs), the resources should 
be capable of providing MIME-typed representations of themselves using the 
normal mechanisms of the Web.  So, when the URIs are http: URIs, the 
resources are (probably) not thought of as attachments and are retrieved 
using the normal mechanisms of http:.  Each particular packaging scheme, 
as described in [1], defines the means by which it uses some particular 
set of URIs for retrieval of representations of attachments.

That's it.  I think it's a reasonable model.  I think WSDL can model it. 
Indeed, I think WSDL needs sooner or later to support this model for 
non-attachment data.  Applying it to attachments is just more metadata, I 
think (this URI will refer to a resource that travels with the message, 
this one won't, and this third one could be either way.)

I really haven't seen either a motivation or an architecturally strong 
design for including image/gif data in an XML Infoset.  Actually, let me 
soften that.  I think the data model given 2 paras above is the right one 
for users.  If someone wants to do a second packaging that uses the XML 
Schema hexBinary or base64Binary and that puts the parts in SOAP headers, 
expanded to character form, I think that might be worth considering.  It's 
not a solution, IMO, to the requirement that we carry binary as binary, 
which is what we're supposed to do here. 

I am very much opposed to any proposal that directly or indirectly creates 
a binary data model in the Infoset at this time.  I think it's a very 
subtle thing to get right, it needs to be very carefully lined up with at 
least the query data model, it breaks a lot of the things we hold dear 
about XML as a text standard, and I certainly don't think it's something 
we should back into in the course of doing attachments.

Noah

[1] http://www.w3.org/TR/2002/WD-soap12-af-20020814/
------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Friday, 31 January 2003 16:54:48 UTC