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