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.
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
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
The following request was submitted on
23/06/2010: