13Special Datatypes
In an app, we have to deal with various types of attributes. While many of them have a standard datatype, like Integer or String, as their range, some of them may have special datatypes as their range. For instance, the Universal Business Language (UBL), which is an industry standard defining document formats for electronic commerce, defines a large set of business datatypes including the following.
| UBL Data Type | Description |
| Date | One calendar day according to the Gregorian calendar. |
| Time | An instance of time that occurs every day. |
| DateTime | A particular point in the progression of time, together with relevant supplementary information. |
| Percent | Numeric information that is assigned or is determined by calculation, counting, or sequencing and is expressed as a percentage. |
| Amount | A number of monetary units specified using a given unit of currency. |
The Semantic MediaWiki151 uses the following special datatypes.
| Semantic MediaWiki Data Type | Description |
| Geographic coordinate | Holds coordinates describing geographic locations |
| Monolingual text | To associate a text value with a specific language code |
| Quantity | Holds values that describe quantities, containing both a number and a unit |
| Record | Allows saving compound property values that consist of a short list of values with fixed type and order |
| Holds e-mail addresses | |
| URL | Holds URIs, URNs and URLs |
| Telephone number | Holds international telephone numbers based on the RFC 3966152 standard |
We discuss several important cases of special datatypes and how to deal with them in the model code and in the HTML user interface code. The following class diagram illustrates examples of attributes having such a special datatype as their range.
In the C++ and C# programming communities, special datatypes like string patterns and quantities are also called “semantic types” (see, e. g., Gibson2016153 and Perdeck2015154).
13.1Boolean Values
Boolean attributes, like isSmoker, can only have one of two possible values: true or false, which are sometimes more naturally expressed with yes or no. In the model code, Boolean attributes are treated like primitive datatype attributes, since all programming languages support Boolean as a primitive datatype.
For rendering a Boolean attribute in a user interface, there are several options. The simplest solution is using a checkbox field. Alternatively, a single-selection list with the two options true and false (or yes and no), or a corresponding radio button group with two radio buttons, could be used.
In an HTML form, a checkbox field is implemented with an input element of type checkbox. For assigning the value of the checkbox field to the Boolean attribute, the field’s checked attribute has to be used, as shown in the following example where we have a checkbox field in an HTML form:
In JavaScript code, the checkbox field is accessed via its name, and the Boolean attribute is assigned by reading the field’s checked attribute (instead of its value attribute), like so:
13.2String Patterns
Email addresses, URLs and telephone numbers are examples of strings that have to match a certain pattern, typically defined by a regular expression. It’s quite common to have attributes with such values. For readability, it’s preferable to use predefined datatypes, like Email, URL and PhoneNumber, in an information design model, instead of defining them as string-valued attributes with a pattern constraint.
In a (JavaScript or Java) model class definition, these attributes have to be implemented as string-valued attributes with a pattern constraint. It is, however, desirable to have built-in support for them, like in the data/document format definition language XML Schema.
13.2.1Telephone numbers
There is much variation in the format of phone numbers across different countries. Consequently, it doesn’t make sense trying to capture all these different formatting options with one pattern. The HTML5 specification doesn’t define any syntax rules for phone numbers in the context of input elements of type “tel”, except that they can’t include line breaks. The precise formatting assumptions and corresponding validation is left to the application developer who may employ a specific pattern for enforcing a particular national or international phone number format.
A simple international phone number format has been defined by the International Telecommunication Union’s ITU-T E123 standard. It requires that phone numbers include a leading plus sign and allows only spaces to separate groups of digits. ITU has also limited the length of phone numbers to at most 15 digits. Since the shortest international phone numbers in use contain seven digits, we can use these two constraints in the following JavaScript definition of a regular expression for international phone numbers:
13.2.2Email addresses
The format of email addresses has originally been defined by the International Engineering Task Force (IETF), but due to several weaknesses it has been redefined in the HTML5 specification in the context of introducing input elements of type “email”. The HTML5 specification provides a regular expression for email addresses155, which can be used for validating strings that are supposed to be email addresses.
13.2.3URLs
The format of URLs has originally been defined by the International Engineering Task Force (IETF), but due to several weaknesses and the historical confusion about URLs versus URIs versus IRIs, it has been redefined in the URL specification156 of the WHAT Working Group. The syntax rules defined in this specification also define the validity of URL strings in input elements of type “url” introduced by HTML5.
There are many proposals157 how to capture the complex URL parsing rules with a regular expression, but most of them are either too strict or too lax. The solution by Diego Perini158 stands out and seems to be a pretty good approximation. As soon as the new built-in JavaScript object type URL is supported by all browsers, a precise validation check will be possible by trying to create a URL object with a given URL string, and then catch any DOMException of type SYNTAX_ERROR.
13.3Special Numeric Data Types
13.3.1Positive and non-negative integers
Since it is common to have positive or non-negative integer attributes, it’s preferable to use predefined datatypes, like PositiveInteger and NonNegativeInteger, as their range in an information design model, instead of defining them with the range Integer and adding a corresponding interval constraint.
In a (JavaScript or Java) model class definition, these attributes have to be implemented as integer-valued attributes with an interval constraint. It is, however, desirable to have built-in support for them, like in the data/document format definition language XML Schema.
13.3.2The unit interval
Certain attributes, e. g., when representing probabilities, have the unit interval [0,1], or one of its open variants, as their range. They can be implemented as decimal-valued attributes with an interval constraint. But having a corresponding predefined datatype, like UnitInterval, is preferable.
13.3.3Percentages
The values of certain attributes represent percentages, which are decimal numbers that have to be divided by 100 for obtaining the numeric value represented by them. In a user interface, the value of a percentage attribute is shown with a % suffix, similar to quantity attributes shown with a unit suffix. For supporting percentage attributes, a special predefined datatype like Percent is needed.
13.3.4Arbitrary precision numbers
In widely used programming languages, like JavaScript and Java, the built-in standard datatypes for dealing with decimal numbers (like number in JavaScript and double in Java) do not support precise calculations. For instance, in JavaScript, the result of computing the subtraction 0.3–0.1 is not 0.2, but rather 0.09999999999999998, which is close to, but not the same as the correct result. Even if such a precision error may be acceptable in a use case like in physics simulation for games, it is not acceptable in a use case like financial accounting.
The concept of arbitrary-precision numbers is to allow calculations where the precision is only limited by the available computer memory, unlike the fixed-precision arithmetic implemented in a computer’s arithmetic logic unit, which is normally employed by the standard arithmetic implementation of a programming language. Arbitrary-precision numbers are used in applications where precise results of calculations (even with large numbers) are required and where the calculation speed is not a critical factor.
In JavaScript, we can use a library like big.js159 or mathjs160 for arbitrary-precision calculations. For instance, using the big.js library, the precise result of the subtraction 0.3–0.1 is obtained in the following way:
The maximum number of decimal places and the rounding mode used to round the results of the critical operations div, sqrt and pow (with negative exponent) is determined by the value of the static properties DP and RM of the Big class, as illustrated by the following example:
The rounding mode property values 0..3 have the following meaning:
| Value | Description | Java BigDecimal equivalent | |
| 0 | Rounds towards zero. I.e. truncate, no rounding. | ROUND_DOWN | |
| 1 | Rounds towards nearest neighbour. If equidistant, rounds away from zero. | ROUND_HALF_UP | |
| 2 | Rounds towards nearest neighbour. If equidistant, rounds towards even neighbour. | ROUND_HALF_EVEN | |
| 3 | Rounds away from zero. | ROUND_UP |
In Java, we can use the built-in datatype class BigDecimal161 for arbitrary-precision calculations. For instance, the precise result of the subtraction 0.3–0.1 is obtained in the following way:
The maximum number of decimal places, called scale in Java, is either set implicitly by the constructor argument or explicitly with
A scale and rounding mode can be set for each operation by providing either a scale value and a RoundingMode enumeration literal or a MathContext object. They should be set at least for the critical operations divide and pow (with negative exponent), as illustrated by the following example:
In this example, the value of the result variable is 0.6666666667.
13.4Calendar Dates and Times
Calendar dates, times of the day and timestamps (date-times) are special data values, which are often only supported for the Gregorian calendar. We use the datatype names Date, TimeOfDay and Timestamp in information design models.
Both JavaScript and Java have a built-in Date class that does actually not represent calendar dates, but rather timestamps (or date-times) in the specific form of the number of milliseconds since 1 January, 1970 UTC.
13.4.1Using JavaScript’s Date class
JavaScript’s Date class allows to represent Gregorian calendar timestamps in the interval of +/- 100 Million days or approximately 285,000 years either forward or backward, from 01 January, 1970 UTC.
A JS data-time can be created in several ways:
A timestamp with the current date and time can be created in the following way:
Assume that the Book model class defined above has an additional attribute publicationDate, the values of which have to be included in HTML tables and forms. While date/time information items have to be formatted as strings in a human-readable form on web pages, preferably in localized form based on the settings of the user’s browser, it’s not a good idea to store date/ time values in this form in a database. Rather we use instances of the predefined JavaScript class Date for representing date/ time values internally and for storing them. The predefined functions toISOString() and toLocaleDateString() can be used for turning Date values into ISO standard date/time strings of the form “2015-01-27”, or to localized date/ time strings like “27.1. 2015” (for simplicity, we have omitted the time part in these strings).
In summary, date/ time values may be expressed in three different forms:
- Internally, for storage and computations, as a
Datevalue. - Internally, for annotating localized date/ time strings, or externally, for displaying a date/ time value in a standard form, as an ISO standard date/ time string, e. g., with the help of
toISOString(). - Externally, for displaying a date/time value in a localized form, as a localized date/time string, e.g., with the help of
toLocaleDateString().
Since the calendar arithmetic and calendar date manipulation functionality of the built-in Date class is limited, using a library like date-fns162 may be helpful for doing more advanced calendar computations.
13.4.2Dealing with calendar dates and times in the user interface
For showing a date/ time value as an information item in a web page, we can use the HTML <time> element that allows displaying a human-readable representation (typically a localized date/ time string) that is annotated with a standard (machine-readable) form of the date/ time value.
We illustrate the use of the <time> element with the following example of a web page that includes two <time> elements: one for displaying a fixed date, and another (initially empty) element for displaying the date of today, which is computed with the help of a JavaScript function. In both cases we use the datetime attribute for annotating the displayed human-readable date with the corresponding machine-readable representation.
This web page loads and executes the following JS function for computing today’s date as a Date value and assigning its ISO standard representation and its localized representation to the <time> element:
For providing better support concerning the user input of a calendar date value in an HTML form-based user interface, HTML5 has introduced the input element types “date” and “time”, which are supposed to instruct browsers to render special UI widgets for picking a date or time. For instance, the following HTML form is supposed to be rendered with a date picker widget:
Unfortunately, in April 2017, a date picker widget has still not been implemented in the Firefox browser, so a progressive enhancement approach is required, where a date picker widget is created with the help of a JS library (like flatpickr163) whenever the current browser does not provide one.
When the user has picked a date in a widget, the input element’s value attribute contains a date string. A simple way to convert this string into a Date value is provided by using the DOM attribute valueAsDate like so:
13.4.3Using Java’s Date and Calendar classes
In Java, we have two important built-in classes for dealing with date-times:
–java.util.Calendar is an abstract class, which provides methods for dealing with calendar timestamps and which has concrete subclasses for specific calendars like the GregorianCalendar. Notice that an instance of Calendar is not a calendar, but a wrapped date-time value. For getting a specific date or datetime, we can invoke the constructor of a suitable calendar class with the desired values:
–java.util.Date is a class that represents timestamps (or date-times) in the specific form of the number of milliseconds since 1 January, 1970 UTC. Most of the methods and constructors of the Date class have been depreciated (because they do not support internationalization), but not the class itself. It is recommended to either avoid using it and use a suitable Calendar subclass instead of Date, or, if an instance of Date is needed, create a Date object by first creating a Calendar object and then converting it to a Date object with the help of the getTime method:
For getting a Date object that holds the current date-time, we can use the constructor without parameters:
It is important to notice that months are represented as integers in the range [0, 11], where 0 denotes the month January and 11 the month December. The days of the month are represented as integers in the range [1, 31]. The hours of the day are integers in the range [0, 23] and the minutes are integers in the range [0, 59].
In many cases, we need to deal directly with values for date-time components like the month, day, hour and so on, instead of just having these values wrapped in an object. The Calendar class defines the get method, taking an integer parameter that allows to specify the desired date-time component in the form of static Calendar properties. For example, if we need to extract the current year, month, day, hour, minute and second, we use the following code:
For more about date/time handling in Java see Chua Hock-Chuan’s Java Date webpage164.
13.4.4Using Date and Calendar with JPA
In an entity class with temporal attributes, having Date or Calendar as their range, we use the @Temporal annotation:
The TemporalType enumeration has three possible values: DATE, TIME and TIMESTAMP, which allow to specify the serialization format used when a Date or Calendar object is persisted in a database. These values correspond to the classes java.sql.Date, java.sql.Time and java.sql.Timestamp, all being subclasses of java.util.Date.
13.4.5Rendering Date Attributes with JSF
Rendering Date-valued attributes requires using the JSF element h: inputText with the attribute p:type="date". This creates an HTML input element of type date. For example, a person’s dateOfBirth attribute can be rendered in a facelet like so:
The JSF converter f:convertDateTime allows specifying an output format for date values. In the above example, we specify four digits for the year, two digits for the month and two digits for the day (e. g., 2015-07-23).
As a result, the following HTML code is generated:
13.5Quantities
A quantity data value consists of a number and a quantity unit. Examples of physical quantity data values (or, simply, quantities) are 1.86 m, 76.5 kg, 44 s, 3.9 m/s, 21 ° C, and 200 mV. Other important examples are monetary amounts like $24.95 or 7 €.
In model object attributes and user interface fields, quantities can be represented by plain numbers, if their unit is retrievable from an underlying datatype definition. It may be desirable that a user interface allows the user to change the unit of a quantity such that the numeric value of the user interface field is automatically converted to the chosen unit.
In a simple approach for supporting quantities, there is a (possibly extensible) set of predefined quantity datatypes such as Length, Mass, Time, Temperature and Amount, each of them associated with a fixed standard unit (such as “m” for Length and “$” for Amount) and an optional base unit such that a quantity data value is a plain number defining the quantity in the base unit, if a base unit is defined, otherwise in the standard unit.
When defining the properties of a class, a quantity-valued attribute would have to be defined by specifying a quantity datatype definition like Length()or Time(Y) as its range. This is, however, not possible in a standard JS constructor definition or an ES6 class definition. Rather, a class definition approach supporting range specifications like cLASSjs165, discussed in Volume 2 of the book, is required.
In this approach, the data value of a quantity attribute would be a plain number that is interpreted in combination with the base unit of the attribute’s quantity datatype. Quantities could be easily converted to other preferred units in a user interface in a generic manner by invoking the conversion functions defined by the quantity unit instances of the QuantityUnit class.
Gibson2016166 reports on a proposal for C++, which allows expressing quantities in a natural way as number/unit pairs in arithmetic expressions based on the C++ features of operator overloading and user-defined literals. For instance, if someone would run 100 meter in 9.58 seconds, a variable for computing her speed could be assigned like so
A general approach to supporting physical quantity datatypes would have to be based on the seven fundamental physical quantity dimensions Length, Mass, Time, Temperature, ElectricCurrent, LuminousIntensity and AmountOfSubstance, which are the basis for defining composite physical quantities such as Area in m2 or Velocity in m/s by defining a map {d1:e1, …, d7:e7} from the fundamental quantity dimensions di to integers ei as exponents of the generic quantity dimension expression:
13.6Complex Data Types
13.6.1Records
Records are composite data values consisting of field slots, which are name-value pairs, such that we can access the value of a record field via its name.
Examples of records are address records like {street: "37 Market St", city: "New York", zipCode: 10473} or phone book entries like {type:"home", areaCode:"757" number:"3765295"}.
13.6.1.1 Color definitions
Colors can be defined with three components on the basis of a color model such as the Red-Green-Blue (RGB) color model or the Hue-Saturation-Lightness (HSL) color model. In both models a fourth component, in the form of a decimal number from the unit interval [0,1] or a corresponding percentage, for defining the opacity (technically called alpha channel) of a color can be added.
In the RGB model, each component value is an integer between 0 and 255. In CSS, an RGB color is specified by a ternary term like rgb( 255, 255, 255) corresponding, e. g., to a JS triple record like {R:255, G: 255, B:255}.
In the HSL model, the H component is an integer between 0 and 360 denoting an angle degree in the rainbow color circle with red = 0 = 360, green = 120, and blue = 240. Saturation and lightness are represented as percentages, such that S=100% is full saturation, and 0% is a shade of grey, L=100% is white, 0% lightness is black, and 50% lightness is “normal”. In CSS, an HSL color is specified by a ternary term like hsl( 0, 0%, 100%) corresponding, e. g., to a JS triple record like {H:0, S:0, L:100}.
In an HTML form-based user interface, color definitions are supported by HTML5 input elements of type “color”, which are to be rendered in the form of a color picker widget.
13.6.1.2 Geo-coordinates
Geographic coordinates (or geodetic positions) can be defined in the form of records like {latitude: 40.6643, longitude: -73.9385}.
13.6.1.3 Rendering records in a user interface
A record-valued property (like geoCoordinates) should be rendered as a list of fields in a coherent region in the UI, preferably with a fieldset element with the property’s label as the content of the legend element. In simple cases, like in the following example, with only a few record fields, using suitable CSS rules, it may be possible to render all fields horizontally on the same line.
Notice how the property geoCoordinates is bound to the fieldset element with the help of the custom data-bind attribute.
13.6.2Data collections
Data collections are ordered or unordered sets or bags (multi-sets), with all members being either primitive data values, records of a certain type or data collections of a certain type. Instead of “unordered set”, we simply say “set”, and instead of “ordered bag” we say “list”.
Examples:
- The nick names of a person may be recorded in a set-valued attribute
nickNames. - The favorite composers of a person may be recorded in an ordered-set-valued attribute
favoriteComposerssuch that the order represents a ranking. - A train trip route may be recorded as a list of train stop locations.
In the user interface, a collection-valued attribute may be rendered as a text field with a comma-separated list of strings if the value collections are sufficiently small. Otherwise, a special table-like UI widget is needed for value assignments and changes.