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

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 31 January 2003 21:53
> To: Sanjiva Weerawarana
> Cc: jones@research.att.com; Martin Gudgin; xml-dist-app@w3.org
> Subject: 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.   

Why does something that requires a change to[1] not relate to things for
which we are gathering requirements? [1] is after all only a WD and
subject to change without notice. Other requirements that we gather for
the concrete feature may also result in changes to[1]

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

I do not propose to change that.

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

I agree entirely.

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

All I'm proposing is that there be a way of building an Infoset from
whatever packaging mechanism we choose. 

> The XML Infoset is the SOAP
> envelope.

Yes, and all the work we have done in the last 2+ years in the XMLP WG
has been focussed on that SOAP envelope and a processing model for that
envelope. I am curious as to what the motivation is for defining
something which steps outside that work.

> It can,
> using the usual mechanisms of the Web, make references to
> resources using 
> URIs.  

Agreed.

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

And all I'm asking is that we provide a way of mapping those
representations into the Infoset of the SOAP envelope. That way we can
continue to leverage the SOAP processing model.

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

I think the SOAP processing model is a major motivation.
  
> 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.  

That's pretty much exactly what I'm suggesting except I think we should
define such a mapping for whatever packing we come up with.

>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'm not arguing against carrying binary as binary.

Gudge



> 
> 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 Monday, 3 February 2003 12:34:39 UTC