UBL NDR 2.0 public review comments

[Juerg Tschumperlin <juerg.tschumperlin@minedu.govt.nz>]

Good morning all,

 

The New Zealand Education Sector has contracted and tasked me with
investigating ways to implement the Education Sector Data Model as XML
Schemas.

 

Early research, and also the New Zealand e-Government Standard, has lead us
to UBL NDR.

 

Over the last 12 months we have tried to learn, understand and apply UBL NDR
1, then 2, in an non-OASIS context. For both UBL NDR versions we have built
prototypes. Here are some of our findings:

 

 

Summary

UBL NDR

- is an excellent, transparent, prescriptive methodology for building XML
Schemas based on XML libraries, that are based on a data model

- defines one standard, coherent way of doing things, when XML Schema itself
offers a myriad of comparable and possible ways

- rules equally apply in spirit to a non-OASIS context

- version 2.0 is superior compared with version 1.0: 

    - Unqualified Data Types are now based on UN/CEFACT data types

    - Validation of code value lists and business rules is now externalised,
separating schema versioning from rules validation versioning

    - Clearer, workable rules for minor and major versioning

 

The shortcomings of version 1 rendered it not suitable for large scale
implementations in the context described below. We now intend to apply UBL
NDR 2.0 instead.

 

 

Rule Amendments

The vast majority of UBL NDR 2.0 rules equally apply in spirit to a non-OASIS
context. We found the rules fall into one of these categories:

- Adopt a rule as-is (21%)

- Adopt a rule in spirit, with some rewording (for example replace OASIS with
our organisation's name) (45%)

- Adopt a rule with major rewording / clarifications due to different context
(22%)

- Drop a rule due to different context (11%)

- Add a  rule due to different context (20 rules)

 

We call the amended rules ESL (Education Sector Language) NDR, to distinguish
them from the unaltered basis, UBL NDR 2.0

 

 

Differing Context

We have attempted to adopt as many UBL NDR 2 rules as possible without
amendments.

In some areas however, we found that the OASIS context is fundamentally
different to ours, warranting amendments.

The differing contexts include:

 

- The business scope is the Education Sector as opposed to UBL's E-commerce

- The name 'Education Sector' may replace the name 'OASIS' in some rules

- The word 'ESL' may  replace the 'UBL' in some rules

- The Education Sector Data Model is not defined as Core Components Technical
Specification (CCTS), which defines BBIE, ABIE, ASBIE. Some references to
CCTS may have to be reworded, referencing the Education Sector data model
instead.

- The Education Sector Data Model is held in UML notation as opposed to UBL
spreadsheets

- The Education Sector expects prescriptive document schemas without
customisation, as opposed to open UBL schemas allowing or even requiring
customisation/extensibility

- The Education Sector expects the ability to define >1 CAC complex Type per
class, allowing for the inclusion/exclusion of differing BBIEs/ASBIEs
elements and/or element optionality/cardinality. UBL allows for one CAC per
class only.

- The Education Sector expects more frequent release intervals when compared
with UBL

- For the Education Sector, XML Schemas in a release package may be of
different versions as opposed to UBL NDR. This allows for frequent releases
of sub-packages, without the need to re-issue possibly unchanged library or
document schema versions.

- The Education Sector expects that Sector library modules can be extended by
the various agencies within the Sector. For example, the Sector CAC can be
extended by an agency CAC. UBL does not have a need for library extensions.

- The Education Sector Data Model contains some abstract classes, which are
not desired at this abstract level in XML Schemas. Non-abstract classes
inherit attributes from abstract classes. Abstract classes are implemented as
abstract CAC complex Types, supporting inheritance in XML Schemas. Some
additional ESL NDR rules cater for abstract classes, as opposed to UBL which
does not contain abstract classes/complex Types.

 

That the Education Sector uses a modelling tool for UML and XML Schema
models, from which we generate XSD files, has not lead to any rule
amendments. In return, this approach supports UML-to-XMLSchema impact
analysis, which is particularly crucial when packaging different Schema
versions in one document schema package.

 

 

Further research is required in the following areas:

- Message context specific restriction of maximum data length (For example,
the maximum length of a cbc:Name in a Person CAC may be longer than in a
CreditCard CAC). Covered as Business Rule using Schematron?

- A clear documentation / partner agreement for which genericode file
versions and business rule versions make up one particular XSL validation
version.

 

  

Conclusions

UBL NDR 1 and 2 has been of tremendous help to us for defining the
methodology and rules for building a working XML library. While we hesitantly
amended some rules, we believe that in spirit we are still UBL NDR 2.0
compliant to the greatest extent possible.

Some critics may say that there are better XML libraries/vocabularies. To
date however we have not seen an applied methodology yet that is as detailed,
clear and coherent as UBL NDR 2.0. In fact, most XML libraries/vocabularies
do not expose the methodology and rules used during construction.
Congratulations to the UBL TC: UBL NDR 2.0 is an excellent piece of work on
standardisation of data exchange, based on a model driven XML Schema library
and UN/CEFACT data types.

 

 

Juerg Tschumperlin

Data Management Solutions

Wellington, New Zealand

 

 

juerg.tschumperlin@minedu.govt.nz <mailto:Juerg.tschumperlin@minedu.govt.nz> 

juerg@paradise.net.nz

 

 

 

 

 

 



DISCLAIMER
This e-mail is intended for the addressee only and may contain information which is subject to legal privilege. The contents are not necessarily the official view or communication of the Ministry of Education. If you are not the intended recipient you must not use, disclose, copy or distribute this e-mail or any information in, or attached to it. If you have received this e-mail in error, please contact the sender immediately or return the original message to the Ministry by e-mail, and destroy any copies. The Ministry does not accept any liability for changes made to this e-mail or attachments after sending.
All e-mails have been scanned for viruses and content by security software. The Ministry reserves the right to monitor all e-mail communications through its network.