During the process of preparing an
integration between XBRL and XForms I’m observing certain areas that would
require additional work from the developer on a form in xforms. This email is
an explanation of one of the issues “the use of xsi:nil” that IMO
is a generic XML issue. That’s the reason the subject of this email is
not related to XBRL. XBRL will be used just as an example of using XForms to
produce or work with XML. The purpose of this email is just to serve as
documentation about this use case.
Use case scenario (High level):
An application would be developed in order
to allow Companies to keep updated their financial information in a server. The
server will use most advances XML technologies available up till now in the
field (an XML database, XBRL and XForms) and will operate on the Internet mostly
using the HTTP protocol. The service will provide the following high level functionalities:
1)Search – Retrieve: Using
a company name and a date, the service will provide and XForms form for the
company in the indicated date. The form will have an existing XBRL instance
document with data (if it was previously submitted) or will contain a new one (empty
XBRL document) just generated so companies can just fill-in the data.
2)Update: the service will
receive an updated XBRL instance document (generated in response to the submit
event), will validate it (according to the XBRL specification) and if it is
valid then it will be stored in the repository for further use. The instance
document contains the company name, the dates for which it contains data and
the data that must be stored.
XBRL is the syntax used to exchange
information between the client and the server (the content of the xf:instance
XForms is the technology used to allow
companies to update the data, produce or modify the content of an existing
Now to the technical details about xsi:nil
In this system, if no previous information
is in the database, a new empty XBRL instance document MUST be generated by the
server. This new instance document would contain a set of elements where the
companies can put the data in. (empty placeholders of data)
For numeric values (as one example, but this
is valid for any other data type), it would not be appropriate to initialize
them with the value “0”. Saying that “cost of sales”
for a company product is 0 is different from saying that there is no value reported
for the “cost of sales” of that product. In this case, xsi:nil=”true”
means “there is no value”.
The XBRL generated automatically will
contain an element like this:
<CostOfSales … xsi:nil=”true”/>
And the meaning of this XML construction is
that “there is no value” for the CostOfSales concept.
The application is providing a placeholder element
to let companies fill-in data if they want.
Now, if the company provides data, the
expected element (generated by XForms) would be.
-The updated version of the fact
do not contains xsi:nil=”false”. I’ve to confess that I’ve
never seen xsi:nil=”false” in an XML document, even if it is valid
according to the XML schema spec. xsi:nil=”false” is a synonym of
saying that this element has a value, so most of the applications just remove
the xsi:nil attribute from the element at the same time a value is set or adds
it if the value is unset.
-The updated version of the fact
contains a new attribute “precision” indicating how the number
123623 must be read by applications. (This is XBRL specific functionality in
regard to the representation of values. A Value must have either a “decimals”
or “precision” attribute and is an XBRL error if it contains both
For those elements where the company has
provided no data, it would be desired that they were removed from the updated
instance. They are placeholders of data that has not been used so they can be
The following xforms elements deals with
part of the ideas I’ve written in this email: