Does anyone know the benefit of specifying your enumerations in a
separate "genericode" file rather than in the XSD itself?
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?
Andrew, the main reason is that a value can be added or removed from a without having to change and re-release the schema.
For the specific case of FpML, for example, most people would not like to have a new release of the whole standard every time ISDA defines new clearing statuses, business centers, indexes, etc.
The bad news is that, as the code lists are not in the schema as enums, your validator can't check them for you. You need to write additional code.
On 29 June 2012 10:23, Andrew Welch <[hidden email]> wrote:
Does anyone know the benefit of specifying your enumerations in a
Daniel Dui - [hidden email] - skype: danieldui
On 29 June 2012 11:00, Daniel Dui <[hidden email]> wrote:
> Andrew, the main reason is that a value can be added or removed from a
> without having to change and re-release the schema.
> For the specific case of FpML, for example, most people would not like to
> have a new release of the whole standard every time ISDA defines
> new clearing statuses, business centers, indexes, etc.
> The bad news is that, as the code lists are not in the schema as enums, your
> validator can't check them for you. You need to write additional code.
Ok thanks - I think we (on this list) talked about this a while back,
the ability for the XSD to read in an xml file at compile time?
In reply to this post by Andrew Welch
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
. 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
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
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:
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:[hidden email]
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
Thanks for all the info Ken, regarding:
> 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.
An example is:
which defaults the "originatingEventScheme" attribute to:
...and that page seems to define the 'allowed' values list, although
from my still naive perspective it looks like some are missing, like
|Free forum by Nabble||Edit this page|