XML

We provide advanced XML interfaces that are easier to use and understand.
Our XML Schema are:

Unnabreviated

Messages are easier to read with element names that are not abbreviated.

Documented

Model documentation is included, making it easier for users and developers to understand elements and components.

Annotated

Annotations reference the source item in the model, along with its semantic markup, and the trace to its business component or element. This traceability enables advanced tools to make use of semantic technology.

Convertible

Messages can now be validated, even when elements appear in any order.
This supports conversion from storage formats where the order of elements may be mixed up, such as JSON/BSON. The order of elements in the model is not significant for formats which include element tags, such as these.
This makes use of an XSD 1.1 feature allowing elements in any order.

Compatible

Messages can now be validated with schema for a different type, enabling compatibility between functions, flavours and versions.

It does this by:

  • specifying the message definition identifier as metadata attributes of the root element with default values;
  • using the same namespace across all schema,
    avoiding the namespace per definition that prevents compatibility;
  • including the message building blocks directly under the root element,
    avoiding the definition specific element that prevents compatibility.

This enables receivers to understand messages when their content is compatible with their schema, even if it was sent for a different version.

Comparison with ISO20022-4:2013

These experimental schema for Messages and Code Sets, have several advantages over those produced by the RA, specified by ISO20022-4:2013:

  • Usable
    • Documented – documentation is included in the schema.
    • Un-Abbreviated – full names are used instead of abbreviations.
  • Compatible
    • No Namespace – namespace is not set,
      allowing schema to validated contents of message.
    • Un-Ordered – elements are now valid in any order,
      supporting translation with JSON, and other orderless formats.
  • Traceable
    • References – trace generated items to e-Repository xmi:ids.
    • Code Sets – logical derive from conceptual, enabling type substitution.
  • Simpler
    • Amounts contain currency as an element, instead of an attribute.
    • The root element contains building block elements directly,
      instead of in an extra element named for the message definition.
    • Root element attributes carry the Message Definition Identifier
      as metadata.

Usability

A problem with 20022-4:2013 is that generated schema
abbreviate element names and omit documentation.
It’d be ok if it was done in the spirit of the standard to use only dictionary abbreviations, such as “id” for “identification”.
However, everything has been abbreviated to the point of obfuscation, making it difficult and confusing for readers. What does “prtry” mean ?

This means readers need to look up what the name means, except that documentation is omitted so they can’t.

These schema use include documentation and use full element names,
enabling users to easily understand the name and find documentation.

Compatibility

A problem with 20022-4:2013 is that generated schema
set individual namespaces and require a specific element order,
preventing compatibility, even between versions of the same message.

Further, the schema requires items in a specific order, which is a problem if you’re converting between formats that don’t retain order. When converted back to XML, elements are often in a different order.

These schema omit namespaces and allows elements in any order.

Traceability

A problem with 20022-4:2013 is that generated schema
always list all enumerated values.

There’s a need to defer selection of a version of a Code Set from design time to run time.

The operational approach has been for messages to reference external logical code sets
that have been modelled as empty, resulting in generation of simpleTypes without codes.

A new approach is to fully model the Code Sets, use semantic markup to indicate they are external, and then generate simpleTypes without codes.

These schema render external logical Code Sets as empty, and other Code Sets as fully enumerated. This enables the external logical Code Sets to be replaced at run time.
These schema also include traceability information to enable linking between Code Sets.

Simplicity

Currency

A problem with 20022-4:2013 is that generated schema
have currency data as attribute of an Amount.

Instead, we generate currency as an element in Amount, because it is business data, not metadata.

Message Definition Identifier

A problem with 20022-4:2013 is that generated schema
have individual namespace based on the Message Definition Identifier, despite being from the same vocabulary.

Namespaces should identify the vocabulary. Instead the namespace in each xml schema has been set to be the URN of the schema itself.

Instead, we generate the Message Definition Identifier properties as attributes of the root element, and set the default values within each schema. In this way, all messages can carry the metadata identifying the message definition they were written with, yet can still be used if compatible with other message definitions.

rootElement

A problem with 20022-4:2013 is that generated schema
include a separate rootElement and type element.

It generates schema with a global element of complexType both named rootElement; which use local element of complexType both named for MessageDefinition. A note says to strip Vxx from the MessageDefinition for the element name.

Operationally, the RA omits generation of the rootElement for the Business Application Header.

Every rootElement in the repository is currently named “Document”.
This would means lots of complexTypes named “Document”,
however they are each in a Message specific namespace.

The meta model show Building Blocks as direct children of the Message Definition, so we should have a rootElement element of complexType MessageDefinition.
Further, as per the note, in the eRepository the rootElement should be set to the MessageDefinition name stripped of the Vxx.
This limits the scope of compatibility to this group of messages.