W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

Re: Media type encoding parameter?

From: Mark Baker <distobj@acm.org>
Date: Thu, 3 Jan 2002 10:35:57 -0500 (EST)
Message-Id: <200201031535.KAA01798@markbaker.ca>
To: jacek@systinet.com (Jacek Kopecky)
Cc: xml-dist-app@w3.org
>  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.

Envelope, encoding, mustUnderstand qnames, DTD indicator.  Note that's
just a list of the bits worth considering.  I'm not suggesting we make
them all parameters.

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

Yes, I did want this with the "envelope" parameter, as I corrected
myself earlier in this thread.

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

Sure, in the same way that the root element may have a namespace that
is recognized, but some contained element may be from an unrecognized
namespace.  But there's still value in exposing the root namespace, as
long as the way it is exposed doesn't suggest that it's the only
namespace in use.  The same could work for encodingStyle.

My earlier question to you, which I thought you answered in the
affirmative, was whether encodingStyle was typically used once at or
near the root of the body block.  To me, that says that it would
therefore be useful to allow implementations to support this parameter.

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

Including "action"?  I thought Henrik described its value well.  I had
suggested the same thing a few months earlier too.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Thursday, 3 January 2002 10:35:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:05 GMT