Next in thread →
Next in month →
Re: [ebxml-msg] Comments on 1.09 schema
Doug: The reason why I had "as required by SOAP 1.1" is because Section 4.2.2 SOAP actor Attribute in the SOAP 1.1 spec states: "Omitting the SOAP actor attribute indicates that the recipient is the ultimate destination of the SOAP message. This attribute MUST appear in the SOAP message instance in order to be effective" Since we want to target the SyncReply element to http://schemas.xmlsoap.org/soap/actor/next which is not necessarily the ultimate destination, the attribute value must appear in the SOAP message instance explicitly. Declaring the attribute as being fixed or default with the above value is not sufficient. I will remove that phrase from future versions of the schema I post. Regards, -Arvola -----Original Message----- From: Doug Bunting <> To: ebXML Msg <> Date: Friday, November 30, 2001 4:11 PM Subject: Re: [ebxml-msg] Comments on 1.09 schema Looks good except that your annotation says this is a SOAP requirement which it isn't. It's something documented in the ebXML MSH specification. I'd just delete ", as required by SOAP 1.1". thanx again, doug ----- Original Message ----- From: Arvola Chan To: Doug Bunting ; ebXML Msg Sent: Friday, 30 November 2001 15:31 Subject: Re: [ebxml-msg] Comments on 1.09 schema Doug: Here is an updated schema that incorporates your latest suggested changes. I am making the actor attribute under SyncReply required for now, with an annotation say that it must be explicitly set to http://schemas.xmlsoap.org/soap/actor/next for now. Regards, Arvola -----Original Message----- From: Doug Bunting <> To: Arvola Chan <>; ebXML Msg <> Date: Friday, November 30, 2001 2:42 PM Subject: Re: [ebxml-msg] Comments on 1.09 schema Arvola, That version is an almost perfect rendition of the changes I recommended. However, you've got incorrect references to the body attribute group and forgotten that "fixed" still allows the mentioned attribute to not appear in an instance, either make it required or don't bother mentioning a value that's already in the documentation. I'd also avoid requiring soap:actor in AckRequested or Acknowledgment since the default actor should be able to act on these elements. My remaining changes look like: 22 s/bodyExtension/tns:bodyExtension/ 98 s|fixed=http://schemas.xmlsoap.org/soap/actor/next|| [Possibly, use="required" might be appropriate here -- I'm not sure. Chris?] 119 s/use="required"// 134 s/use="required"// 168 s/bodyExtension/tns:bodyExtension/ 179 s/bodyExtension/tns:bodyExtension/ thanx again, doug ----- Original Message ----- From: Arvola Chan To: Doug Bunting ; ebXML Msg Sent: Friday, 30 November 2001 10:29 Subject: Re: [ebxml-msg] Comments on 1.09 schema Doug: I really appreciate your thorough review of the 1.09 schema. The updated schema draft-msg-header-05.xsd is attached. Please see below for the actions I have taken. Regards, -Arvola -----Original Message----- From: Doug Bunting <> To: ebXML Msg <> Date: Thursday, November 29, 2001 4:27 PM Subject: [ebxml-msg] Comments on 1.09 schema Arvola, The current schema has a few mismatches with the specification and inconsistencies between our extensions. Some of these issues may need to be resolved through changes to the document instead. I'll start by suggesting changes to the schema. thanx, doug Generally: Push content of Error element and the optional xml:lang attribute down into an optional list of Description elements. Implemented in my list of changes. As mentioned in my "first half" comments, this might be overkill -- an optional Description would be fine. I have pushed the Error content and the xml:lang attribute into an optional Description element. Suggest we remove messageOrderSemantics attribute and require SequenceNumber in MessageOrder. I did not implement this change in my list, just commented on the issues. Agreed and done. For future versioning capabilities, we should support wildcard element content in every SOAP extension we define and in the "larger" repeating elements within those elements. About all I'd exempt is eb:PartyId since that's very extensible already (name/value pairs). Without this, we don't support easy extensibility and will have to replace the schema for every improvement made. As I commented in my versioning note (http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00274.html), wildcard elements support vertical extensions and our own versioning pretty well. Agreed and done. Including wildcard attributes in the Schema Instance namespace on the Manifest and MessageHeader would seem to support adding the xsi:schemaLocation attribute to those elements. However, we've defined 9 SOAP extensions and the other 7 don't allow these attributes. The simplest thing would be to recommend use of xsi:schemaLocation only on the parent soap:Envelope, soap:Header and soap:Body elements. Next in complication would be allowing xsi:schemaLocation only for all our extension elements and documenting that option in the specification. I'd prefer to limit future extensibility to the wildcard elements we've already documented and should add to a few more elements. Removed all wildcard attributes. A few more comments in the schema would help, especially ones that tell readers where an element might appear in a SOAP instance. Done. Attribute groups would make the schema much more readable. One that contains (optional) eb:id and eb:version would be applicable for every SOAP extension we've defined. Another that adds (required) soap:mustUnderstand could be used in our soap:Header elements. Since soap:actor is only used in a limited selection, that shouldn't be part of any group. I haven't defined these groups in my detailed changes below. Introduced two attribute groups headerExtension.grp and bodyExtension.grp. You've defined defaults for the SOAP attributes that SOAP requires to have values in the instance. (SOAP processors are not required to validate received documents prior to dispatch.) At most, what's currently defined as a default should be mentioned in schema comments. Better would be leaving it out entirely. Done. Line by line in draft-msg-header-04.xsd: 15 s/MANIFEST/MANIFEST, for use in soap:Body element/ 24 d [Remove the two anyAttribute cases.] 46 s/MESSAGEHEADER/MESSAGEHEADER, for use in soap:Header element/ 64 d [Remove the two anyAttribute cases.] 93 s/default="false"/use="required"/ [This is presently an optional attribute in an otherwise empty and optional element. Other option would be to require QoS in MH but that adds useless text to an instance.] 96 s/SYNC REPLY/SYNC REPLY, for use in soap:Header element/ 98 a <sequence> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> 102 s/default="urn:oasis:names:tc:ebxml-msg:actor:nextMSH"// 105 s/MESSAGE ORDER/MESSAGE ORDER, for use in soap:Header element/ 109 a <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 114 s/default="NotGuaranteed"/default="Guaranteed"/ [The unguaranteed use of a sequence number seems like a remote use case, default to expected one. I'd actually prefer to eliminate this attribute and require the SequenceNumber element rather than complicate things with this "require this element if this attribute is set this way".] 120 s/name="type"/name="status"/ [big one!!] 125 s/ACK REQUESTED/ACK REQUESTED, for use in soap:Header element/ 127 a <sequence> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> 131 s/default="urn:oasis:names:tc:ebxml-msg:actor:toPartyMSH"// 132 s|/>|use="required"/>| [Tri-state Booleans (missing, true or false) don't make sense within optional elements. Specification doesn't say anything about the cardinality of this attribute. Let's make it always present when the AckRequested element appears.] 135 s/ACKNOWLEDGMENT/ACKNOWLEDGMENT, for use in soap:Header element/ 142 a <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 147 s/default="urn:oasis:names:tc:ebxml-msg:actor:toPartyMSH"// 150 s/ERROR LIST/ERROR LIST, for use in soap:Header element/ 154 a <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 159 s/default="Warning"/use="required"/ [Should be consistent with Error@severity and we document both attributes as having calculated values (no defaulting).] [It's a larger change (and would change the specification) but I'd like to remove the optional xml:lang attribute and make the contents a sequence of Description elements and / or any elements. Next three changes are what that would look like:] 164-165 d 164 a <complexType> <sequence> <element ref="tns:Description" minOccurs="0" maxOccurs="unbounded"/> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> 170-172 d 175 s/STATUS RESPONSE/STATUS RESPONSE, for use in soap:Body element/ 180 a <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 187 s/STATUS REQUEST/STATUS REQUEST, for use in soap:Body element/ 191 a <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 232 s/default="1.1"// [This attribute is required wherever it's used. Default is meaningless.]
Next in thread →
Next in month →