Next in thread → Next in month →

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

From
Pim van der Eijk <>
Date
2010-07-07T08:17:02+00:00
ID
C604297812794B1EAECBE7D5021DD766@Roussanne
Thread
RE: [ebxml-msg] Re: 15-day Review Request for ebms-header-3_0-200704_refactored
Hello,

 

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

 

Pim

 

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:] 
Sent: 26 June 2010 10:25
To: 

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

 

Hello,

 

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.

 

Pim

From: Mary McRae 
[mailto:] 
Sent: 24 June 2010 
16:34
To: 
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.

Regards,

Mary

On Jun 23, 2010, at 2:32 PM,  
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

          

             
            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.
Next in thread → Next in month →