This version has been superseded by this new proposal 

A prior proposal is here.

Introduction

Much data contains numeric values that are enumerations, with corresponding logical strings that provide the symbolic interpretation of them.

...

It has been suggested that the transformations expressed here between numeric and symbolic data would be useful in contexts outside of DFDL, and that this proposal could be formulated as an extension of XSLT or XQuery. This is certainly the case. What is presented first here is presented in the context of DFDL however.

Proposal

Each enum value for a string simple type can be annotated with properties that give the corresponding numeric value(s) either as a discrete list, or as a numeric range.

...

When both dfdl:lookupRange and dfdl:lookupKey are specified, then the dfdl:lookupRange is used when parsing, the they are combined to create the aggregate set of values and ranges for parsing. When unparsing the first dfdl:lookupKey is used when unparsing. The When unparsing, if no dfdl:lookupKey value must fall within an inclusive interval defined by the lookup rangeis specified, then the lowest value of the first specified dfdl:lookupRange is used.

Given these annotations, a DFDL processor can provide a logical string in the infoset, where the underlying representation is integer. Unparsing inverts the logical value back to a physical integer.

...

Note that the above can be implemented without use of advanced DFDL features like dfdl:inputValueCalc. The simple existence of an element with a dfdl:repType property would enable an implementation of this table-lookup capability without the need for a complete implementation of DFDL's expression language.

Recasting the Proposal for use Outside of DFDL Context

If the above were re-cast for use in XSLT or XQuery, or in Schematron assertions, etc. then the sensible thing would be to provide these same annotations on a XSD schema, along with an XSLT function that can be called, passing an element of the physical type to get out a value of the logical type, or vice versal. The function would be given the type name of the logical type. E.g., assume namespace prefix f, the functions might be

f:lookupRep(logicalTypeQName, ...value of the rep type...) returns value of the logical type
f:lookupValue(logicalTypeQName, ... value of the logical type... ) returns value of the rep type

Multi-Dimensional and other Complex Lookups and Function

Note: This is a more advanced feature. Not initially part of the proposal, but here for initial feedback.

...