The ORM Foundation

Get the facts!

How to use regular expressions for a Value Range

Last post Thu, Jul 12 2012 20:22 by Matthew Curland. 3 replies.
Page 1 of 1 (4 items)
Sort Posts: Previous Next
  • Thu, Jul 12 2012 6:59

    How to use regular expressions for a Value Range



    I have a value type named Identifier in an ORM model which has to comply with the following regular expression [Aa..Zz]{[Aa..Zz]|[0..9]}*. I have tried putting the expression in the field ValueRange of the value type properties window. However it is not allowing me to use this type of regular expression.

    How can I specify this kind of Value Type?


    Many Thanks in advance

    Filed under:
  • Thu, Jul 12 2012 14:20 In reply to

    Re: How to use regular expressions for a Value Range

    Hello Nieves,

    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.


  • Thu, Jul 12 2012 14:59 In reply to

    Re: How to use regular expressions for a Value Range

    Hi Matt,

    Thanks for the explanation :D If it is on the road-map for the coming months, it should be fine.

    However your answer has just reminded me of another issue that I face almost daily with the Value Types. And maybe you can tell me if it is on the going or not.

    My recurring problem comes from those Value Types that may have different data types and until run time you do not know which one will be.

    I put an example: Alumn gets Grade, and Grade depending on the teacher, subject or moment can be signed integer, float or string. For these situations, It would be nice to have either a general data type for the value type or better yet allow multiple data types. 

    Currently, I have to make a much more complicated model with an intermediate entity type and fact types with all the possible types  as value types and exclusiveIncluse constraints between the types; like  Alumn gets Grade,Grade consists of IntegerNumber or Grade consists of FloaNumber or Grade consists of StringGrade...

    Do you think this could be solved with a new value constraint?  or some other new modificationthat may be coming?

    Thanks in advance


    Filed under:
  • Thu, Jul 12 2012 20:22 In reply to

    Re: How to use regular expressions for a Value Range

    Hi Nieves,

    This isn't something that would be solved by standard data types, but custom data types could conceivably be modeled this way by allowing optional values in the identifying structure of the data type. Essentially, you're asking to model something like a good old fashioned COM VARIANT type and use that as a data type. The main issue is mapping this to different implementation targets. COM used a C union, so all different types of data was stored in a minimal amount of space. However, this is not easily mapped to all physical implementation targets.

    One way to model something like this is similar to how values are stored in NORMA. Here, the value is always stored as a string, which is then interpreted as a typed value based on data type associated with the value. This allows consistent storage (although not necessarily small if you're storing an integer in string form) of all of the values regardless of the underlying type. If you also store the type of the underlying value, you can interpret the string data as the proscribed type when the data is extracted.

    So, the bottom line is that upcoming changes will not immediately enable a union-style data type like you're talking about here, but it isn't something I'm completely ruling out in the future.


Page 1 of 1 (4 items)
© 2008-2020 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service