- From: Marc Hadley <marc.hadley@sun.com>
- Date: Mon, 13 Aug 2001 15:03:04 +0100
- To: Noah_Mendelsohn@lotus.com
- CC: "Nilo Mitra (EMX)" <Nilo.Mitra@am1.ericsson.se>, xml-dist-app@w3.org
May I suggest the following rewording of the sentence in question: Current: "The SOAP mustUnderstand attribute is useful for detecting situations in which required software is not available at a node which has been correctly targeted;" Suggested "The SOAP mustUnderstand attribute is useful for detecting situations in which a SOAP block targetted at a node is not understood (see 2.4 Undestanding SOAP Headers) by that node;" The first paragraph of 2.4 contains the following sentence which explains the meaning of "understand" in this context: "We say that a SOAP header block is understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that block." Regards, Marc. Noah_Mendelsohn@lotus.com wrote: > I suggest that these sorts of clarifications are the types of things that > we normally leave the discretion of the editorial team, and I am happy to > leave it to them. > > I do agree that the word "correctly" in your #2 isn't quite right, but I > think the point I am attempting to make is essential and could easily be > lost: the purpose of mustUnderstand is not to deal with any failures of > the targeting mechanism. It applies in the situation where a message is > "correctly targeted", has been delivered to the intended point in the > message path, the software at that point is correctly assuming its > intended roles, but for some reason that software is not configured to > provide functions that are essential to the correct processing of the > message. So, we need a pithy phrase that conveys all that. I agree that > my phrasing isn't quite dead on, but at least it was short and crisp. I > see that as one of the most crucial clauses in the formulation, and I > suggest that the editorial team attempt to reformulate it in a manner that > is clear and to the point > > ------------------------------------------------------------------------ > Noah Mendelsohn Voice: 1-617-693-4036 > Lotus Development Corp. Fax: 1-617-693-8676 > One Rogers Street > Cambridge, MA 02142 > ------------------------------------------------------------------------ > > > > > > > > "Nilo Mitra (EMX)" <Nilo.Mitra@am1.ericsson.se> > 08/07/01 10:14 AM > > > To: "'Noah_Mendelsohn@lotus.com'" <Noah_Mendelsohn@lotus.com>, > xml-dist-app@w3.org > cc: > Subject: RE: mustUnderstand reformulation > > Hello Noah: > I have two comments on your joint reformulation for mU: > 1) Suggest replacing "endpoint" with "ultimate SOAP receiver" > 2) First part of first sentence of proposed new second paragraph: > >>The SOAP mustUnderstand attribute is useful for detecting >>situations in which required software is not available at a >>node which has been correctly targeted; >> > I think this sentence is a bit confusing, and seems to not quite fit with > the > rest of the para which discusses what to do when the targeted node was > never reached. > If the node has been "correctly targeted" and "the required software is > not available", > then section 4.2, second para seems quite clear that the node should not > "process the SOAP > message at all, and fail." > I'm also a little concerned that the proposed *specification* text is > straying > from what must be done, or what must happen to guidelines/suggestions for > how to deal > (albeit interesting) situations. > If this *part* of the first sentence were removed, and it started "It is > not intended..", > I don't think your points would be lost. > Thanks > Nilo > nilo.mitra@ericsson.com > > >>-----Original Message----- >>From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com] >>Sent: Monday, August 06, 2001 5:12 PM >>To: xml-dist-app@w3.org >>Subject: mustUnderstand reformulation >> >> >>Glen Daniels and I were asked to propose a reformulation for >>"mustUnderstand". What follows is a first cut for review and >>discussion by >>the workgroup. The reformulation also attempts to remove >>overlap between >>section 4.2.3 and the processing model stuff. We did this in >>parallel with >>Mark Hadley's work on eliminating overlap, so we probably >>unintentionally >>duplicated some of his effort. Presumably, the two >>approaches can easily >>be reconciled if the workgroup believes that our overall direction is >>correct. >> >> >> > > -- -- Marc Hadley <marc.hadley@sun.com> Tel: +44 1252 423740 Int: x23740
Received on Monday, 13 August 2001 10:04:16 UTC