RE: [ebxml-msg] Schema Related

["Ben Malek, Hamid" <HBenMalek@us.fujitsu.com>]

Pete,

Here are few corrections to be made either to the schema itself of within the spec in order to synch them both. I only did a very superficial reading of the spec. During the second review, I might do a deep reading of it, and I am sure there will be more issues (not necessarily related to the schema).

 

Issue 1: On page 77 (lines 3172 to 3179), the documentation mentions only PullRequest and Errors within a SignalMessage and does not mention the newly added Receipt signal.

 

Issue 2: On page 78, line 3193, the schema defines the element "ErrorDetail" with a capital letter E (which is correct). In the spec, line 2038, the ErrorDetail is written with a lower case e (as errorDetail). This should be corrected.

 

Issue 3: this is similar to issue 2. On line 3196, the schema defines an attribute called "RefToMessageInError". This attribute should be written with a lower case r as "refToMessageInError (page 51, line 2035 is using the attribute with a lower case r).

 

Issue 4: On page 41, line 1505, the spec declares the element "AgreementRef" as being optional. However the schema (line 3165 does not say it is optional). Schema needs to be corrected here.

 

Issue 5: On page 39, line 1393, the example is showing the element service with a type attribute. However, the schema (on line 3266) declares the element service as a simple element (does not have any attributes). If the spec is correct in this case, then the schema needs to add such an attribute to the service element, otherwise remove the "type" attribute from the example.

 

Issue 6: In the schema (page 77, line 3127), it is declared: attributeFormDefault="unqualified". This means that an attribute within a local element should not be qualified (local element is any element that resides as a child or grandchild of the element <eb:Messaging>). However, in the spec (page 39, line 1407) displays an example where the "location" attribute is qualified. The same thing goes for the attribute "version" which is being qualified in the example, while the schema says that it should not be qualified.

 

Issue 7: The spec on page 38, line 1350, says that the SOAP mustUnderstand attribute is REQUIRED, but the schema on page 79 (lines 3332-3333) says the attribute is optional. One of them should be changed (either the spec or the schema).

 

Issue 8: This is just a suggestion. Currently the schema says attributeFormDefault="unqualified" (meaning that attributes within local elements should not be qualified). However, I suggest that we add a sentence to the spec (at the beginning of the "Packaging" section that says that attributes could be qualified or unqualified (that is we accept both forms), and in the schema documentation we mention that too. This would ensure that if an implementation is qualifiying attributes, while another implementation does not, they would still be able to read each other.

 

Hamid.