[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.