MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ebxml-msg] Updated Schema
Jeff,
A few comments, realizing this is an early draft of the schema:
- I do not understand why HeaderBaseType is used so frequently. Can
PayloadInfo, Payload, Processing, Step and Error all appear at the top
level (that is, directly within soap:Header)?
- We were previously quite explicit about where "unknown" elements may be
inserted through judicious use of the <any /> extension point. Which
elements now require this extension point and should we be similarly
explicit in the new schema?
- The headerExtension.grp attribute group allows (but does not require)
soap:mustUnderstand through its <anyAttribute /> extension point. The 2.0
schema explicitly required this attribute on every header element.
- The 2.0 schema did not use a base type for all headers. In the new
schema, we are using a base type which includes an <any /> extension point.
This means the <any /> extension point for the affected elements (see
first two points above) has moved from the end of the content model to the
start.
- Where the same element name is used with the same type multiple times, we
should probably be consistent and use a top-level <element /> declaration.
Role is one candidate for a new declaration.
- The PayloadInfo / Payload / Processing / Step / Parameter hierarchy seems
rather complicated. How would overall processing of the entire message be
described? I am not sure why we need to contain the list of Payload
elements inside an otherwise-empty PayloadInfo element. Similarly, why not
create a list of ProcessingStep elements directly in the Payload (or
Payloads for overall processing should we allow that)? Do the steps
require a sequence identifier in addition to ordering the list? Should the
Parameter@value attribute instead be carried as the Parameter content (that
is "<Parameter name='foo'>bar</Parameter>" rather than "<Parameter
name='foo' value='bar'></Parameter>")? My apologies if I have previously
missed a discussion of this part of the schema.
- We have an open 2.0 issue about the Schema element. My previous
suggestion was that this element identify the relevant namespace as well as
the version and location.
- How is the Service element's content model different from that of Action?
It seems like no actual extension occurs for Service and the content
model could be simplified to make this more explicit.
- Creating MessageHeaderType (which is used just once) seems inconsistent
with the rest of the schema. Why not just put the content model within the
MessageHeader element declaration?
- How is the tns:non-negative-integer type different from
xs:nonNegativeInteger? Using xs:nonNegativeInteger in the sequence
attribute declaration (the only place this type is used) seems easier than
creating a vacuous restriction.
- The names of the various types declared seem inconsistent. I can
understand HeaderBaseType (and MessageHeaderType) for a type used only in
element declarations. But, status.type and non-empty-string (for example)
do not follow a similar capitalization rule and identify their "typeness"
differently or not at all. We should either capitalize all types
consistently or come up with a split (element / attribute type) rule that
covers non-empty-string (used in both attributes and elements). All type
names should consistently have (or not) a "Type" or ".type" suffix.
thanx,
doug
On 27-Jan-05 09:22, Jeff Turpin wrote:
>
>
> ------------------------------------------------------------------------
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/members/leave_workgroup.php.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]