W3C home > Mailing lists > Public > public-forms@w3.org > May 2008

Use of xsi:nil in XML -> inpact on xforms.

From: Ignacio Hernández-Ros <ignacio@reportingstandard.com>
Date: Sat, 31 May 2008 16:37:00 +0200
To: <www-forms@w3.org>
Cc: <public-forms@w3.org>
Message-ID: <016301c8c32b$ccb54160$661fc420$@com>
Hello,

 

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.

 

Regards,

Ignacio

 

Ignacio Hernandez-Ros 

XBRL Expert

Reporting Estandar S.L.

 <mailto:ignacio@reportingstandard.com> ignacio@reportingstandard.com

 <http://www.reportingstandard.com> xbrl.reportingstandard.com
Cell: +34 609027754

 
Received on Saturday, 31 May 2008 14:37:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:48 UTC