RE: [ebxml-msg] Re: 15-day Review Request for ebms-header-3_0-200704

Last week we agreed to discuss some options for refactoring the schema on the mail list. Here are some comments on two of them.

1) The approach outlined in my email below and in the Part 2 PRD is to have a separate schema with the namespace of ebMS 3.0 but in a different schemaLocation. There is some accepted precedents in using this approach in schema customization, for instance in the UBL guidelines for customization. A UBL customization or profile, like an EDI MIG, can make changing like making optional elements mandatory, or removing them from the schema. Users of this customization can validate their instances using modified versions of schema files. A requirement is that any document that validates against the modified schema must also validate against the unmodified schema. In the case of our refactured schema, this is true also except that the refactored schema has other global elements than eb:Messaging, so documents using those global elements are also valid against the refactored schema. However, section 5 of the ebMS 3.0 Core Specification makes very clear that the root element to be used in ebMS 3.0 SOAP messages is the eb:Messaging element. So I believe that any ebMS 3.0 MSH can work with either the unmodified or the refactored XSD without interoperability or conformance issues. There are lots of XSDs that define multiple elements where in an application context only one or some are to be used as root element. So it still seems an approach that does not violate any XML schema best practices and introducing the refactored schema with Part 2, without any updates to the Core spec, is a valid option.

2) Issue an errata for the Core Spec. This seems OK too. But when we do this, we should also collect and fix any other issues with the core spec we know about (I've come across a few and others perhaps have too).

P.S. ebMS 2.0 could also benefit from an erratum too. There are some minor known issues with the schema, and the standard has an existing user community with new deployments starting even in 2010.

My proposal is that we include the refactored schema as a separate deliverable of Part 2. It is a schema with the same namespace as the Core schema. A schema that uses it, imports it using a distinct schemaLocation value. I think this is acceptable as:

- an XML document is valid according to the refactored schema iff it is valid according to the core schema and

- any element in a valid XML document has the same XML schema type when parsed into an InfoSet using either of the two schemas.

The upcoming v64 has the schema in a new appendix B.

I'm not sure what this is or what you're trying to do. ebXML Messaging 3.0 is an OASIS Standard. If you want to make any changes whatsoever they either need to fall under the errata process (which it sounds like this isn't) or to create a 3.1 version of the spec and proceed through the normal document cycle. It's impossible to change just the schema without changing the document itself - even if it's just updating the cover page metadata and including a new schema link.

Mary

On Jun 23, 2010, at 2:32 PM, ebxml-msg@lists.oasis-open.org wrote:

The following request was submitted on 23/06/2010:

Submitter's Name

Ian Jones

TC Name

OASIS ebXML Messaging Services TC

TC Email Address

ebxml-msg@lists.oasis-open.org

Specification Title

ebms-header-3_0-200704_refactored

Resources

ebms-header-3_0-200704_refactored.zip

Approval Link

http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/38380/MessagingTC060210.htm

Previous Public Review Announcement

http://markmail.org/message/ld5yttxstl3cf6oi?q=ebxml+list:org%2Eoasis-open%2Elists%2Etc-announce&page=2

Abstract

Refactored header XSD in preperation for Part 2 messaging specification review - all existing XML will still be valid and this is a re-organsiation of the XSD to allow re-use of strutures and elements in new data structures to be introduced in Part 2 of the specification which will be sent for ful review shorrtly.

TC Description

Development of adittionl functiopnality of the ebXML messaging service specification to support more e-business functionality as requested by the user community.

Notes

This is a review of the XSD only no changes have been made to the specification and no materail changes to the functionality have occuured this is a tidy and improvement of the XSD after implentation and user feedback to easy part 2 development.

ebxml-msg message