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

+1

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

xml-dist-app-request@w3.org wrote on 01/31/2003 04:52:35 PM:

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