[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Data entry of coded values for UBL or any XML document when using the UBL Methodology for Code List and Value Validation
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]