MHonArc v2.5.2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
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.
- Suggest we remove messageOrderSemantics attribute and require
SequenceNumber in MessageOrder. I did not implement this
change in my list, just commented on the issues.
- 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.
- 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.
- A few more comments in the schema would help, especially ones
that tell readers where an element might appear in a SOAP instance.
- 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.
- 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.
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.]
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC