OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.

From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: 26 June 2010 10:25
To: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Re: 15-day Review Request for ebms-header-3_0-200704_refactored

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.

From: Mary McRae [mailto:mary.mcrae@oasis-open.org]
Sent: 24 June 2010 16:34
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Re: 15-day Review Request for ebms-header-3_0-200704_refactored

Hi Ian,

  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.



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
Specification Title
Approval Link
Previous Public Review Announcement
  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.
  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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]