Value constraints currently support only value ranges (for ordered data types) and single values (for unordered). The notion of a regex expression is a more sophisticated case that I classify (using XSD terminology) as a facet. Theoretically, each data type supports different sets of facets, and each value constraint should be able to provide a value for one or more facets associate with that data type. Of course, just as with value ranges, a specified facet would need to be more restrictive than the data context the facet is applied in.
In the coming months, NORMA data types will be extended as follows:
The user will be able to place data types on a diagram and establish simple type hierarchies, much like the XSD simple type. Data types will be displayed like object types with a dotted line. This allows users to define data type restrictions locally and reuse these restrictions instead of reapply the restrictions for each use. For example, a 'MediumLengthString' could be defined centrally in the model.
Each data type will define its own set of facets. Currently, we use Length and Scale as the two predefined facet buckets and adjust the display name of these slots depending on context. This is a hack and needs to be formally modelled so that each data type can have its own facet mappings.
Value constraints and restricted data types will be able to apply any of the defined facets.
Data types will be able to participate in calculated fact types with other data types. These fact types can then be used as functions and operators in derivation rules.
Users will be able to graphically display the relationship between a value type and its associated data type (tentatively using a lightweight dashed line. Note that this is not considered a subtyping relationship and will not be drawn as such.).
Initially a set of standard data types will be provided along with their facet definitions, functions, and operators. Eventually custom top-level data types may be supported as well, but this has a number of other issues, such as mapping the data types to physical implementations.
The regex (XSD pattern facet) has its own set of difficulties with implementation because of the different levels of regex support offered in different systems. For example, .NET supports a much richer regex language than XSD. This may require multiple regex expressions for different physical targets. Of course, multiple styles of regex can also be difficult to verify.
There are a few design issues to work through in this area, such as parsing and display and different facets, but the metamodel elements are well-understood. Basically, we know this area needs improvement, but there isn't anything available right now.