Data entry of coded values for UBL or any XML document when using the UBL Methodology for Code List and Value Validation

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

I've had a number of requests for clarification of the use of 
genericode and methodology files for data entry tools.  Here are some 
initial thoughts to share publicly for anyone interested in creating 
a data entry environment that would match up with a customized 
two-pass validation environment.

The data entry of element and value structure of information items in 
UBL instances by people can be directed by authoring tools aware of 
the XSD-expressed structural and lexical constraints of the UBL 2.0 schema[1].

An early version of the UBL Methodology for Code List and Value 
Validation[2] was used to create the defaultCodeList.xsl second-pass 
value-validation stylesheet in the UBL 2.0 deliverable[3].

The latest version of the methodology produces a 
defaultCodeList.xsl[4] with the identical constraints, but improved 
error messages based on the use of the reference implementation of 
ISO Schematron now available on the ISO Schematron web site[5].

The inputs to the methodology stylesheets are the UBL genericode 
files[6] and context/value association files[4].

Until now the publishing of the context/value association files has 
been awaiting maturity of the methodology and the finalization of 
genericode.  This finalization hasn't happened yet, but there is some 
interest in seeing the context/value association files and Schematron 
files used to create the validation stylesheet so that they can be 
taken advantage of in data entry applications.

Of course during data entry an application can attempt to run a 
Schematron validation when data values are entered, reporting 
violations triggered by the assertions in the Schematron 
schema.  This may be intensive on large instances but is probably 
viable for small instances being edited by people in real time.  When 
the value is entered, the Schematron schema could be run and errors 
presented to the document author.

But post-entry validation, even on a per entry basis, doesn't give 
the document author direction on the valid values available to be 
entered as enumerated in the associated genericode files.

There are context/value association files for each individual 
document model and for the aggregate of all document models[4].  A 
data entry tool has enough information in a given document model's 
context/value association file to find, for each contextual coded 
information item (be it a code list or identifier list) with an 
associated genericode file, the address of the genericode file and 
through that the list of values allowed for the given document context.

Given that the negotiation between two trading partners may engage 
different context/value association files (e.g. the standard UBL 2.0 
file for a document type, a layered industry-specific association 
file for a customization, and a further layered 
trading-partner-specific association file for a given transaction), 
the data entry tool needs to support multiple references to 
context/value association files in order to know for each contextual 
information item the codes available that will pass the second-pass 
value validation stylesheets created by the same set of context/value 
association files.

With this dynamic configuration a data entry tool can then create a 
trading-partner specific editing environment tailored to both phases 
of the two-phase validation:  XSD structural/lexical validation and 
XSLT value validation.  When switching the data entry tool 
configuration between different trading partners, all of the 
drop-downs and other entry of code lists and identifier lists will 
switch to the suite of values matching the second-pass validation 
used for each respective trading partner.

This introduces the data entry concepts in broad strokes.  The 
current methodology documentation[2] doesn't address data entry as it 
was written to describe only validation.  I'll consider adding the 
above information as an informative annex to the methodology in a 
future edit of the documentation.

Please let me know if you have any questions on the above as this 
will direct me in the editing of the informative annex.

Thanks for your feedback!

. . . . . . . . . . . . Ken

[1] http://docs.oasis-open.org/ubl/os-UBL-2.0/xsd/
[2] http://www.oasis-open.org/committees/document.php?document_id=22591
[3] http://docs.oasis-open.org/ubl/os-UBL-2.0/val/
[4] http://www.oasis-open.org/committees/document.php?document_id=23531
[5] http://www.schematron.com/implementation.html
[6] http://docs.oasis-open.org/ubl/os-UBL-2.0/cl/gc/

--
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal