W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2002

Issue 51: Should soap:header@part be nmtokens? (was RE: ACTION: All wg members to review editorial issues by July 11)

From: Liu, Kevin <kevin.liu@sap.com>
Date: Tue, 9 Jul 2002 04:32:34 +0200
Message-ID: <99CA63DD941EDC4EBA897048D9B0061DA9520D@uspalx20a.pal.sap-ag.de>
To: "'Jonathan Marsh'" <jmarsh@microsoft.com>, www-ws-desc@w3.org

Issue 51 (see [1]) involves some design considerations. Though the lengthy text of the issue may have made it confusing, the key point is about how WSDL should deal with soap:body and soap:header construction. WSDL1.1 has different constructs for body and header, but doesn't provide any justification about the differences:

>> The combination of soap:header@message and @part allows one to define re-usable messages for soap headers, but WSDL1.1 only allow you to specify *one part* of a message at a time, whereas soap:body@parts allows specifying *a list of parts* of a message at one time to be included in soap body. 
>> Unlike soap:header, soap:body does not have @message.  

Given the fact that soap:body is just a particular kind of soap:header, it's not clear why wsdl should treat them so differently, in particular:

>>Should we change soap:header@part of type nmtoken to soap:header@parts of type nmtokens to allow specifying multiple parts of a message to be included in soap header?  

>>Should we also provide an optional soap:body@message attributes and make it default to the enclosing input/output message?In other words,  Is there any valid use cases for  including parts from messages other than the enclosing input/output message in soap:body?
>>How about soap:headfault and soap:fault, should they also be symmetric?

Regards,  Kevin

[1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x51

-----Original Message-----
From: Jonathan Marsh [mailto:jmarsh@microsoft.com]
Sent: Thursday, June 27, 2002 12:45 PM
To: www-ws-desc@w3.org
Subject: ACTION: All wg members to review editorial issues by July 11

In today's telcon, we agreed on a plan to give the editors discretion to
resolve issues that are purely editorial without individual WG
discussion (specifically, telcon time).  The WG is given two weeks (till
July 11) to review the issues list and identify issues mis-classified as

Through reverse engineering, I am defining "Editorial" as any issue that
doesn't require WG discussion and decision to resolve.  It may be that
you feel that the prose describing a particular feature would benefit
from WG discussion, in which case you should propose a reclassification.
For example, the input/output terminology issue we discussed and
resolved this morning would not be classified as Editorial according to
this definition.
Please also feel free to suggest alternate resolutions or other
clarifications to an issue during your review, but please distinguish
between helpful advice and a request to reclassify the issue.

The consolidated issues list is at
Received on Monday, 8 July 2002 22:33:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:24 UTC