Jose,

It may be clearer (semantically) to state that the soap:Envelope and soap:Body and all children of the soap:Body MUST NOT be encoded with an env:encodingStyle attribute.   Therefore, concretely eliminating the usage of the env:encodingStyle attribute guarantees that the message (body content) is literal XML.  This imo is semantically clearer that stating un-encoded, because one could argue that an env:encodingStyle attribute with a value of 'empty string' (this indicates no claims are made to the encoding) could be allowed which may be confusing.

Thx,

-Matt


--
Matt Long
MV Squared Technologies
mlong@mvsquared.net
901-848-2640


--------- Original Message --------
From: jose.kahan@w3.org
To: "Matt Long" <mlong@mvsquared.net>
Cc: www-xkms@w3.org
Subject: Re: Semantic Nit
Date: 22/06/05 10:54

Hi Matt,

I showed the original text and your proposed modificationss to Carine
Bournez and she said that:

<quote>
I think it is equivalent, but the original text was more clear about what
"unencoded" means (i.e. not using the optional SOAP 1.2 encoding).
Literal is quite obscure to me.
</quote>

Is there a definition some place of how the coding of the content
for Body:literal should be done? If not, I propose we just remove the
rationale and leave the paragraph as:

<quote>
XKMS implementers shall use SOAP document style request-response
messaging with the XKMS messages defined in Part 1 carried as unencoded Body
element content.
</quote>

Thanks,

-jose

On Wed, May 18, 2005 at 04:27:47PM -0000, Matt Long wrote:
> Section 3.1.1 (Binding) See [1]<?xml:namespace prefix = o ns = "urn:schemas-
> microsoft-com:office:office" />
>
> "XKMS implementers shall use SOAP document style request-response messaging
> with the XKMS messages defined in Part 1 carried as unencoded Body element
> content. The SOAP 1.2 RPC representation, and requisite encoding style, are not
> used. The potential benefits of using the RPC representation do not justify the
> additional effort required to define a mapping from the Part 1 messages to an
> appropriate encoding style."
>
> Suggest:
> XKMS implementers shall use SOAP document style request-response messaging with
> the XKMS messages defined in Part 1 carried as a literal Body element content.
>
> Justification:
> It is unambiguously clear that the XKMS message is of document-literal form.
> The semantic justification of why encoding was not selected is irrelevant.
>
> Comments?
> [1] http://www.w3.org/TR/xkms2-bindings/#XKMS_2_0_Section_3_1



________________________________________________
Message sent using UebiMiau 2.7.2