Tuple Dimension, Typed Dimension, Data Modelling in XBRL Implementation

One of the questions which taxonomy builders face relates to making choices in modeling certain types of information given that there are multiple ways in which data can be defined in XBRL.  

Let us take example of reporting framework which requires a company to list all their offices with address and number of employees working in that office. In this case the list is unknown while defining the taxonomy. There are two ways in which the unknown list can be defined in XBRL i.e. Tuple and Typed Dimensions. The parameters which go into the taxonomy for this unknown list are office name, address and number of employees.

Tuples
Tuple definition for above example would require company to report details for each office in blocks. While creating instance document it is necessary to keep information pertaining to one office together within a block of XML tag. Each block of information is not uniquely identified. If a concept ‘number of employees’ is read in isolation there is no way to identify to which office it belongs.

Typed Dimension
Now, if the example is represented using typed dimension, each office record would have a separate identity. Parameters pertaining to the same office would be assigned the same unique identity. This unique identity is defined in context declaration called as typed member. Here it is not necessary to keep information pertaining to one office together, syntactically it could be anywhere in the instance document. All concepts in isolation can be related to which group it belongs.

Using typed dimensions, you can also define a pattern for identifying for each record. Say a regulation captures sales and cost structure of each product the company deals in; and there is a standardized list of product code which follows a pattern (first 3 characters capital letters followed by 4 digit numeric code). In this case it makes more sense to use typed dimension as unique identity for each record can be the product code itself conforming to the pattern.

For creators of instance documents tuple may appear easier, however with improved XBRL tools available, the user experience for tuple and typed dimensions should not lead to a significant difference. The unique identify of each record achieved in typed dimensions is useful when the underlying data has to be queried, analyzed or consumed for further data mining. 

One more factor that needs to be taken into account would be the size of instance document. In tuple kind of scenario, the size of the instance is much less than those of typed dimension. This is mainly because the additional identity is established for each record, runs into minimum three lines of code. Say there are 5000 records then you would have 15000 lines more in typed dimension based instance compared to a tuple instance. This could become critical if XBRL intends to capture transactional data which may run into thousands of records.

On the whole, the choice between Tuple or Typed Dimension approach for a particular taxonomy could be driven by factors such as data analysis requirements, ease of use, need for unique identify pattern and document size optimization.