Re: Media type encoding parameter?

 Mark,

 > [on charset parameter]
 > But my point in bringing it up was to show that it isn't required
 > that a parameter be used to make dispatching decisions, as you
 > stated.

 My statement that parameters MUST be used for dispatching (if I
made it in this form), must be lessened, that's true.
 Still I don't think it's appropriate to enhance MIME type
information to subtyping when the subtype is apparent from the
data.

 > >  On the other hand namespaces or any other XML information from
 > > the document is always in the document.
 > True, but being available in the body does not preclude it from
 > being made available elsewhere.  Sometimes there are practical
 > considerations.

 I agree practice can lead to mixing of layers and that it is not
necessarily bad. It's just my feeling that in SOAP no parameter
need to be added to the MIME type, we already have SOAPAction
MIME header used in the HTTP binding.

 > >  If I take your words literally, you again want every bit of the
 > > message outside of the envelope, for generally every bit of the
 > > message can affect success or failure of processing.
 >
 > That doesn't follow.  Not every bit of a SOAP message can affect the
 > processing of a message.  For example, a SOAP processor isn't required
 > to look at the bits in the body block.

 An intermediary SOAP processor is not required to examine the
Body, but a general SOAP processor may fault on Body.

 > The only bits I'm interested in *considering* to be copied outside the
 > envelope are the ones that might cause faults.  See part 1 sec 4.4.5
 > for that list.

 Every failure in processing of a message SHOULD be represented
as a SOAP fault and such failures can occur because of just about
any part of the message in general (though in particular the case
may be that only headers might cause a fault in a concrete node).
 I think I'd like you to list the bits you mean because any
application failure might be represented as a Sender fault.

 > > and now we could argue about what's
 > > reasonable and prudent outside of the envelope. I say, for SOAP,
 > > nuffin'. If we were talking about a parameter of a type
 > > application/xml, that would be different, for the root namespace
 > > could be useful indeed.
 >
 > How would that be different?

 In XML in general, there is at most one namespace identifier on
the root element, which is also only one. Knowing this might be
useful.
 In SOAP, we might indicate this, too, but then we would only
indicate the SOAP version (if we keep versioning through
namespaces). This is the only thing I could see as somewhat
useful, but I don't think you wanted precisely this.
 We might also indicate the encodingStyle attribute on the
Envelope element (or on the Body element), but neither case
necessarily means anything because the actual data could have
their own encodingStyle value.
 We might indicate the namespace of the first header entry or of
the first body entry or something but in the header case the
actual header may not be directed at the node, and in the body
case some applications may do boxcarring and have multiple
namespaces on multiple elements inside the body.
 In any case, I don't see practical usefulness of that except in
very special scenarios.

 > > Even though, AFAIK, encodingStyle is commonly used on the body
 > > and there is usually only one, I dislike the trouble we'd get
 > > into in trying to handle the unusual and uncommon cases. Once
 > > there is only one something, like the root namespace of an XML
 > > document, I'm OK with optionally indicating it outside of the
 > > envelope, too,
 >
 > There can be more than one namespace too.  We could refer to the
 > "root encodingStyle", and treat is we would the "root namespace".
 > I don't see the difference between the two.

But encodingStyle has no practical meaning on the Envelope or
Body or Header because the structure of these elements follows no
known encoding style. So extending this, there is no practical
"root encodingStyle". On the other hand, in the general XML case,
the root namespace has a definite meaning for the root element
does belong to that namespace.

To summarize, I don't think anybody has presented rationale for
any parameter to the SOAP MIME type except for "it might be
useful" which I find too weak for the addition.

Jacek

Received on Thursday, 3 January 2002 09:27:38 UTC