Thanks. Actually, the latest WD sometimes refers to multiple forms ("If MU is "true" or "1""). I think we can take that down to one form ("if MU is "true"") and then use the proposal as I suggest below. Thanks. ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------ "Jean-Jacques Moreau" <moreau@crf.canon.fr> 12/20/2001 07:11 AM To: Noah Mendelsohn/CAM/Lotus@Lotus cc: xml-dist-app@w3.org Subject: Re: Two issues to be opened relating to my rewrite for Issue 101 (and one more already resolved) +1 for the resolution on your first issue (excerpt appended below) noah_mendelsohn@us.ibm.com wrote: > * For envelope attributes, we should use the proper XML Schemas simple type > terminology, carefully indicate when we are referring to lexical vs. value > space, and if a subtype is used (e.g. a boolean that only accepts lexical > form "1"), make clear that we are doing so. > > We do not currently have an issue open on this. I propose that we open > such an issue and resolve it along the following lines: we should > indicate, probably in chapter 4, that "attributes in the SOAP envelope > described by "Part 1: Framework" are are of types from XML Schema: > Datatypes (e.g. mustUnderstand is a boolean). Unless otherwise stated, all > lexical forms are supported for each such attribute, and lexical forms > representing the same value in the XML Schema value space are considered > equivalent for purposes of SOAP processing. Thus, the boolean lexical > forms "1" and "true" [ref to boolean datatype in the schema spec] are > interchangeable. For brevity, text in this specification refers only to > one lexical form for each value (e.g. "if the value of mustUnderstand is > "true"). Unless otherwise stated, such references implicitly cover all > forms corresponding to the same value in the value space. However, when a > header block is relayed by an intermediary [see section 2.6], the lexical > form of any attributes within that block MUST be preserved. "Received on Thursday, 20 December 2001 10:25:10 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:05 GMT