W3C home > Mailing lists > Public > xmlschema-dev@w3.org > June 2012

Re: genericode.org

From: G. Ken Holman <gkholman@CraneSoftwrights.com>
Date: Fri, 29 Jun 2012 09:22:53 -0300
Message-Id: <>
To: xmlschema-dev@w3.org
At 2012-06-29 10:23 +0100, Andrew Welch wrote:
>Does anyone know the benefit of specifying your enumerations in a
>separate "genericode" file rather than in the XSD itself?

Perhaps I can help.  I chair the OASIS Code List Representation 
Technical Committee http://www.oasis-open.org/committees/codelist/ 
that shepherded Tony Coates's genericode into an OASIS Committee 
Specification http://docs.oasis-open.org/codelist/ns/genericode/1.0/ 
. A related Committee Specification is my Context/Value Association 
file that associates XML document contexts with genericode files.

Genericode files express enumerated values with their value-level 
metadata in a list with its list-level metadata.

CVA files express the association between instance-level metadata 
found in an XML document for a given element or attribute to the 
user's desired genericode file with the values for that element or attribute.

Recognizing trading partner relationships are fluid, but the document 
structures between trading partners should be standardized, a 
two-step validation of documents seems appropriate:  the first step 
being document based validating element structures (hierarchical) and 
value structures (lexical) using a static schema, and the second pass 
being actual value checking using, for example, XSLT or Python (as 
two of the implementations of Schematron).

I've published a free developer resource at 
http://www.CraneSoftwrights.com/resources/ubl/index.htm#cva2sch that 
converts a combination of CVA and genericode files through an ISO 
Schematron script into an XSLT stylesheet.

As many non-technical people are involved in negotiating the trading 
partner agreement between parties, I've also published free 
stylesheets at 
http://www.CraneSoftwrights.com/resources/ubl/index.htm#codess for 
both genericode files and CVA files.

One aspect of flexibility using this approach is to constrain the 
same element in two different contexts of an XML document to have two 
different value constraints by the values found in two different code lists.

As well as having fluid value validation constraints, another benefit 
of associating genericode files with XML documents using CVA files is 
in data entry:  a data entry application could implement drop-down 
menus that in each document context presents the union of associated 
code lists and populates the instance-level metadata constructs with 
the appropriate list-level metadata values.

There is a quiet (so far) developer list for OASIS genericode and OASIS CVA at:


I've published a PDF book that describes these relationships, and the 
complete text is available on a try-and-buy basis:  if you don't want 
to keep the book, I ask that you delete what you downloaded, if you 
do want to keep the book, I ask that you buy it.  The complete book 
is found through links here:

  Practical Code List Implementation

I'm teaching this book material as a day-long hands-on training class 
in Europe in November:


An example deployment of genericode/CVA/XSLT files and two-pass 
validation is found in the latest public OASIS UBL draft (another 
draft of which is coming soon):

  Value validation documentation:
  Value validation association:
  Genericode files:
  XSLT created from CVA/genericode through Schematron:
  Running demonstration of two-pass validation:

I created the OASIS UBL artefacts using the free developer resources I cited.

When using OASIS UBL it is expected that a user community will create 
an XSD subset of UBL schemas for the document and value structures 
for standardization and read-only access by all parties in the 
community.  Also, a base set of value constraints using CVA and 
genericode would be published for trading partners to start with in 
building the fluid relationship of values expected in their document 
exchanges.  The XSD files never change, while the XSLT is subject to 
change.  Application developers accommodate all possible values that 
might make it through value validation, and the code lists applicable 
for a given relationship gate the instance as being value-valid or 
not before passing on to the application for action.

This two-stage validation is described and illustrated in an annex of UBL:


... and in my book.

>For example, I'm currently working with the FpML 5.3 XSDs which for
>some fields allow any value, but specify a productIdScheme attribute
>which points to a genericode list.
>One example is: http://www.fpml.org/coding-scheme/originating-event
>Is anyone familiar with that technique?

I haven't seen genericode files pointed to directly from scheme 
attributes before.  To me that seems too restrictive and doesn't give 
the flexibility to users to react to changes to trading partner 
relationships (say, limiting payment means after a cheque bounces).

But, then, I'm unfamiliar with the workings of FpML so I'm not sure 
how the association is being made.  I've not seen a genericode URL 
used as a scheme URI as you imply.

Anyone on the list is welcome to ask me questions about genericode, 
on or off the list:  how about on the list to discuss the 
relationship between genericode and XSD validation (which is used in 
OASIS UBL) and off the list for all other kinds of questions?

I hope this is helpful.

. . . . . . . . . . Ken

p.s. an unrelated use of OASIS genericode files that I've found very 
helpful is that it is a useful XML serialization of a sparsely 
populated table.  As such, I've used genericode to serialize tables 
that have thousands of rows where only a few columns on each row have values.

Public XSLT, XSL-FO, UBL and code list classes in Europe -- Oct 2012
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/x/
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal
Received on Friday, 29 June 2012 12:41:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:16:02 UTC