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 element).
XForms is the technology used to allow companies to update the data, produce or modify the content of an existing XBRL.
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.
<CostOfSales … precision=”INF”>123623</CostOfSales>
Note the following changes:
- 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 of them).
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 safely discarded.
The following xforms elements deals with part of the ideas I’ve written in this email:
<xf:bind nodeset="//*[@xsi:nil]" relevant="count(text())>0"/>
<xf:bind nodeset="//@xsi:nil" relevant="count(text())>0"/>
The elements with xsi:nil attribute and no value will be discarded in the serialized output.
The xsi:nil attribute nodes for those elements that contains data are also discarded and will not be serialized.
Hope this explains how xsi:nil can be used to indicate the existence of data and how this is different from using the empty or identity element for an operation as a possible value.
Reporting Estandar S.L.
|Free forum by Nabble||Edit this page|