RE: Binary attachments to XP

> > No, not at all - if you look at the SOAP Attachment spec,
> it provides a
> > mechanism for having links anywhere in the SOAP message point and of
> > course these can point to anywhere including to other
> entities within a
> > MIME multipart. This works both in the header and parts in
> the body.
>
> If MIME is not part of the spec, then wrapping the MIME around the
> envelope breaks "the binding", meaning that any twist in
> content, not in
> the basic model, that exceeds SOAP breaks "the binding" or
> really just
> breaks SOAP and calls for a new incompatible MIME-based protocol that
> may or may not need SOAP as an attachment, because the container is
> redundant at best.

Could you please provide a specific example of where the SOAP attachment
spec breaks SOAP?

> While the MIME URI concept in Mime Attachments is very good, the
> referencing aspect of the Soap Attachments spec seems
> extremely limited
> and tied to the questionable chapter 5 encodings.  It does
> not seem to
> say how I can move each orthogonal header and body each to
> its own MIME
> encapsulation and rely on them being there when I process any
> message so
> I don't have to XML Parse the parts I don't care about.  Why should I
> have to read multiple MIME parts if all I need is one?  Chances are,
> they will come in the wrong order, so by the time I realize I
> need one,
> I have already skipped it.  This seems very inferior to using MIME as
> the envelope, which permits me to recognize each orthogonal
> module as it
> comes for what it is.

I am not quite sure what you point is here. In SOAP attachments, all you
need is to read the root entity which in practice is often the first
entity. Whether you stick the data within XML Protocol blocks directly
in the XML Protocol envelope of whether you stick a reference to
somewhere else is up to you.

Could you please express a specific example of where the referencing
aspect of SOAP attachments is limited? What is it you can't point to?
Don't confuse this with wanting to describe a manifest concept which the
SOAP attachment spec explicitly claims to be out-of-scope for that spec.

> > There is a very great deal of discussion in the W3C AC forum mailing
> > list archives [1] when the briefing package was discussed. For many
> > reasons we were asked to design an XML protocol with an XML envelope
> > which would allow us to bind to a variety of protocols.
>
> Unfortunately, this seems like a technical judgement, whether
> to use XML
> as the package.  The AC reps were asked to set far too much in stone,
> that hopefully we can convince them to vote against now that
> we have had
> to wrestle with it, especially if we have not been permitted to
> seriously consider the obvious alternatives.

Regardless of whether you think the AC did the right thing or not I am
surprised that you haven't mentioned your concerns and the "obvious
alternative" when discussing the requirements document which clearly
talk about an XML envelope. In fact I checked the mail archives for XML
Protocol discussions and did not find a single comment on this out of
the total of 18 mails that you have sent on XML Protocol throughout the
lifetime of the activity.

> >> Or, can you answer Ray's
> >> arguments? For
> >> example, is it valid for Ray to say that the single document
> >> alternative
> >> necessitates the full parsing of the document before the
> >> header attributes
> >> can be processed? Or, are there ways to manipulate an
> >> event-driven parser to
> >> suspend parsing of the document after the header has been
> >> parsed and to
> >> resume parsing after the contents of the header have been
> validated?
> >
> >
> > There are many ways that one can imagine doing record
> marking - HTTP for
> > example provides a content-length mechanism that makes it
> possible to
> > skip parsing of the XML Protocol body. One can imagine
> similar mechanism
> > for other underlying protocols - or even as you say - smart
> XML parsers.
>
> You have lost me here.  How does the HTTP content length help
> at all to
> skip parsing of the XML Protocol body?  If I want to stop, I can stop
> reading the socket.  But if I am an intermediary, I cannot drop the
> payload, so I will have to read it all anyway and reconstruct
> the rest
> of the document and patch it up for any additions and pass it through.

I think you have seriously misunderstood the SOAP HTTP binding and how
it relates to HTTP intermediaries. The SOAP spec is actually quite clear
on this [2]. If you are an HTTP intermediary then you don't look at the
SOAP message in the HTTP payload at all but simply pass it through as
usual. Note btw that this is a lot less simple if you are using MIME
multipart.

If you are a SOAP intermediary (and if HTTP is used then an HTTP origin
server) then you have to parse the SOAP headers but not the body. As an
added help, one can use the content-length trick I mention above.

> A smart XML parser and the necessary processors would be a
> big complex
> implementation (especially for processing a small piece), compared to
> MIME.  It does not permit most existing tools to be used
> without a lot
> of SOAP-specific work, because XML has never been intended to
> be used as
> a packager for independent parts.  Independent parts have
> typically been
> called documents in the past.

Wow - before anybody can claim to be a good spokesperson for what XML
was intended for, I would like to point to the XML namespace spec which
explicitly talks about mixing vocabularies.

Btw, most parsers are pretty good at ignoring what they don't care about
but I am sure you are aware of that.

> > One on hand MIME multipart has a place in the world but on the other
> > there are several reasons why one would not want always to
> wrap things
> > up in MIME multipart: It makes it impossible to refer to
> entities with
> > reasonable URIs, it makes caching impossible, it complicates access
> > authentication to name a few.
>
> I cannot make much sense of these claims.
>
> URIs can easily refer to MIME parts, and using XPointer to any node
> within those parts.  I have implemented lots of models of
> authentication, and do not understand why you think it complicates
> that?  SOAP Attachments and even the first part of this
> message was just
> talking about how easy it was to refer between attachments.
> It seems an
> advantage to have full modularization so that authentication can be
> modularized where appropriate, which does not prevent you from
> authenticating multiple modules.
>
> > I have no problems with a binding to MIME multipart being
> defined but
> > let's acknowledge both sides of the story and work on a
> solution that
> > has the right modularity to handle both cases in the same
> way that we
> > shouldn't provide a solution that is only suited for HTTP.
>
> First make a case that the SOAP envelope works significantly
> better for
> something important than the MIME envelope, and then we can start
> counting cases.

In the last f2f meeting (where you were not present) I actually did
provide a mapping for SOAP/1.1 to the XML Protocol requirements [1]
which in fact did not run into any substantial problems in doing so. Are
you by the statement above indicating that the requirements are silly and
that we as a WG clearly have missed the mark?

> Your criticism seems to better describe what is wrong with an all-XML
> proposal like SOAP.  Advocating SOAP Attachments does not
> seem to serve
> either side well.  Trying to use XML as the packager is calling
> packaging a nail because we have an XML hammer (but none of the real
> tools we need to make the hammer do the job).  It seems quite
> flawed as
> a packaging solution even for orthogonal pieces of XML, let alone for
> other things, due to the complexity and contextual nature of an XML
> Fragment -- look at the complexity of the XML Fragments
> specification if
> you doubt this.  I believe that XML tools will have to be
> significantly
> rewritten to handle big messages efficiently (and I suspect you will
> have to further subset XML), with much more difficulty than
> for a simple
> MIME parser that properly modularizes independent parts, and you will
> still have significant cases of parts that will have to be
> sluffed off
> outside the "protocol" because SOAP made it impractical by
> choosing an
> XML subset for packaging.  MIME is the simpler, more complete
> packaging
> solution.  Why use XML?
>
> And why do you claim the MIME envelope would only be suited
> for HTTP?
> An application that needs attachments would need them regardless of
> whether the protocol was HTTP, SMPT, or raw sockets.  It is required
> everywhere you need attachments, and would arguably also work
> better for
> the attachments that do work inside of SOAP.  MIME was developed for
> SMTP, not HTTP.
>
> Show me a transport that does not need attachments, and I
> will show you
> an application that does not need SOAP, because that is what the SOAP
> envelope and orthogonal headers are all about, if only it solved the
> attachments as completely or efficiently as MIME.  MIME seems
> like the
> right modularity for most independent entities/headers I can
> think of,
> including XML ones, in small cases.

I am not sure here what your argument or point is but without more
concrete scenarios that back up the claims that SOAP attachment breaks
SOAP or that SOAP itself is broken or doesn't substantially meet the XML
Protocol WG requirements, I find it hard to evaluate the claims.

On a more general note, I find it hard to even have a discussion of
whether to define a protocol based on MIME multipart or on XML. The two
exhibit very different properties and there is no way that you can get
the same properties out of both worlds.

SOAP took a route that defined a processing and evolvability model for
the SOAP envelope and allowed MIME multipart to be used as a container.
This is in fact allows both XML and MIME to be used for what they are
good at - expression of hierarchical data and encapsulation of entities.

I think you have a good point in indicating that it would be useful to
be able to define a protocol binding that includes MIME multipart
support - SMTP comes to mind - and I have no problem saying that the
HTTP binding also should support MIME multipart.

What I do have a problem with is what I read as your claim that MIME MUST be
present and in fact *is* XML protocol as there is nothing that indicates this
in the WG requirements, in the WG charter, or in the arguments that you have
presented so far.

Henrik

[1] http://www.w3.org/2000/xp/Group/0/12/xp-f2f-redmond-soap-mapping
[2] http://www.w3.org/TR/SOAP/#_Toc478383526

Received on Monday, 22 January 2001 14:18:47 UTC