Re: Language for resolving issue 440

Marc Hadley <[email protected]>
Newsgroups gmane.text.xml.distributed
Message-ID <[email protected]>
On Jan 15, 2004, at 8:40 PM, [email protected] wrote:

> Marc Hadley asks:
>
>>> I don't recall - do we already have text that
>>> captures the other part of the resolution,
>>> namely that MTOM doesn't preclude additional
>>> parts in the package not reference via
>>> miffy:Include ?
>
> Did we conclude that?

Yes, we did.

>   More specifically, did we conclude that for Miffy
> or for the HTTP binding as well?

For both. The variability we introduced between XOP and MTOM was 
related to the cardinality of inclusions: we concluded that in XOP 
there could be multiple inclusions of the same binary part but that the 
HTTP binding would restrict it to a single inclusion of any binary 
part. Both HTTP binding/MTOM and XOP would allow unreferenced 
attachments but they are outside the SOAP processing model.

Marc.

>  Not surprisingly, I'm fairly strongly
> opposed to allowing variability in the content sent by the HTTP 
> binding.
> That said, I may just be repressing memories of a decision that went
> counter to my preferences.
>
> I've just read the review copies of the specs, and regardless of what 
> our
> issue resolutions say (and they should be clear), the current miffy 
> text
> does allow for separate parts.  The HTTP binding could probably be read
> either way, since it says to make a part for each optimized piece, but
> doesn't really say whether that means >only< for each optimized piece. 
>  I
> think we should remind ourselves what the resolution is on the http
> binding, and clarify the MTOM document either way.  I think I can live
> with the variability in Miffy/XOP.
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Products, Technologies and Standards, Sun Microsystems.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.